From duke at openjdk.org  Wed Feb  1 07:14:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 1 Feb 2023 07:14:55 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset
In-Reply-To: <1su0_EK4Sx_blL9MQLS7147NWLaYH80QCSvM2iyV7h4=.6c053033-45ce-4234-912c-3de05ee0ef46@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <1su0_EK4Sx_blL9MQLS7147NWLaYH80QCSvM2iyV7h4=.6c053033-45ce-4234-912c-3de05ee0ef46@github.com>
Message-ID: <NAyN1NNVtwqZo__rU87kBdCzJovXOLv-_gM7S1R4BeU=.4ea64600-7f83-4595-807d-007ed53229f0@github.com>

On Tue, 31 Jan 2023 16:02:07 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 432:
> 
>> 430:         if (totalSeconds % (15 * SECONDS_PER_MINUTE) == 0) {
>> 431:             int slot = cacheSlot(totalSeconds);
>> 432:             ZoneOffset cached = SECONDS_CACHE.get(slot);
> 
> I miss `AtomicReferenceArray::computeIfNull` that atomically will compute an element if the value at a certain index is `null`.

@minborg You could compareAndExchange in a CompletableFuture?if you succeed you can complete it with the computation (bonus points since the computation can be done async) and if you fail you get either a value or a CompletableFuture you can decide if you want to block on it, and for how long?

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From stsypanov at openjdk.org  Wed Feb  1 07:19:19 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Feb 2023 07:19:19 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v2]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <cWhV737xlTeebLP1pgncFuPqMC1X-IM_Y8-naZf-SnA=.6e0d306f-c6fc-40cc-bb10-d05cf1886fcd@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Fix logic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/b74164a3..82b03202

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12328/head:pull/12328

PR: https://git.openjdk.org/jdk/pull/12328

From aturbanov at openjdk.org  Wed Feb  1 08:00:51 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 1 Feb 2023 08:00:51 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>

On Tue, 31 Jan 2023 15:57:43 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

src/java.base/share/classes/java/time/ZoneOffset.java line 147:

> 145: 
> 146:     /** Cache of time-zone offset by offset in seconds [-18h, +18h] for each even quarter of an hour. */
> 147:     private static final AtomicReferenceArray<ZoneOffset> SECONDS_CACHE = new AtomicReferenceArray<>(MAX_SECONDS_CACHE_SLOT * 2 + 1);

Can we use regular array instead?

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From rgiulietti at openjdk.org  Wed Feb  1 10:26:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 1 Feb 2023 10:26:26 GMT
Subject: <i18n dev> RFR: 8300869: Make use of the
 Double.toString(double) algorithm in java.util.Formatter [v8]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/5e488a70..bf7d9f64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12259&range=06-07

  Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12259/head:pull/12259

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Wed Feb  1 10:26:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 1 Feb 2023 10:26:27 GMT
Subject: <i18n dev> RFR: 8300869: Make use of the
 Double.toString(double) algorithm in java.util.Formatter [v7]
In-Reply-To: <p3INCZYlaAZF00qaPkL5OOF079XlElugdRDOe3vEXUo=.b4fc5759-7387-4521-8c15-424980d44c8c@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <nOpniQff5eA8HQLfs3OlhcJUvYCK29-RF41KNkbyc-I=.ad311826-3f61-46f2-b5c5-6a8015067bfc@github.com>
 <p3INCZYlaAZF00qaPkL5OOF079XlElugdRDOe3vEXUo=.b4fc5759-7387-4521-8c15-424980d44c8c@github.com>
Message-ID: <4FDCIv_rq0v1SUez4QWFS_45ja2Wdp6uvud9mv2vElM=.58113abe-beb3-498f-ae8d-cbbeb440780d@github.com>

On Tue, 31 Jan 2023 22:19:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>
> src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 28:
> 
>> 26: package jdk.internal.math;
>> 27: 
>> 28: public final class FormattedFPDecimal {
> 
> I suggest adding a short explanation of what this class is used for.

Addressed.

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From stsypanov at openjdk.org  Wed Feb  1 10:36:12 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Feb 2023 10:36:12 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Restore logic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/82b03202..2b07e47e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12328.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12328/head:pull/12328

PR: https://git.openjdk.org/jdk/pull/12328

From pminborg at openjdk.org  Wed Feb  1 11:41:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 11:41:16 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v2]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <HBHnOjm6nfd5ENpq8sATk_HpLtcsu73V7OekzluMWF4=.dd8ff1c1-0be3-4d01-a722-0c2edb6da5eb@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework using a regular array and acquire/release semantics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/eedec09d..a99dd083

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=00-01

  Stats: 43 lines in 1 file changed: 33 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Wed Feb  1 11:41:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 11:41:18 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v2]
In-Reply-To: <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
Message-ID: <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>

On Wed, 1 Feb 2023 07:58:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework using a regular array and acquire/release semantics
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 147:
> 
>> 145: 
>> 146:     /** Cache of time-zone offset by offset in seconds [-18h, +18h] for each even quarter of an hour. */
>> 147:     private static final AtomicReferenceArray<ZoneOffset> SECONDS_CACHE = new AtomicReferenceArray<>(MAX_SECONDS_CACHE_SLOT * 2 + 1);
> 
> Can we use regular array instead?

We can but that entails special handling to ensure thread-safety. I will provide such a solution. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Wed Feb  1 12:06:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 12:06:25 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v3]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <aT7UpnfCt_KjdNSuivnJwMH3uFFOfsGP247_zDODBno=.8c4ea21e-1052-4128-a946-5b2cd72db03d@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove code commented out

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/a99dd083..5a8e9720

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=01-02

  Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Wed Feb  1 13:18:31 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 13:18:31 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Simplify benchmark
 - Add benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/5a8e9720..562885c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=02-03

  Stats: 70 lines in 1 file changed: 70 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Wed Feb  1 13:40:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 13:40:52 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
Message-ID: <BaYxA84q3TgEJfSaZTSKdwIQv-3pXNPK1uCVdrRWcwI=.77ca6006-d3ad-4dd5-a06c-9a013a72d245@github.com>

On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify benchmark
>  - Add benchmark

A > 3X performance increase is obtained via this PR for `ZoneOffset::ofTotalSeconds` for values from the cache (higher is better):


Baseline
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  1.088 ?(99.9%) 0.019 ops/us [Average]
  (min, avg, max) = (1.046, 1.088, 1.109), stdev = 0.018
  CI (99.9%): [1.069, 1.108] (assumes normal distribution)

PR
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  3.710 ?(99.9%) 0.031 ops/us [Average]
  (min, avg, max) = (3.651, 3.710, 3.745), stdev = 0.029
  CI (99.9%): [3.680, 3.741] (assumes normal distribution)


![image](https://user-images.githubusercontent.com/7457876/216058153-03c06037-5ddb-40cb-8e2c-5beae0560126.png)

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From stsypanov at openjdk.org  Wed Feb  1 18:59:51 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Feb 2023 18:59:51 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
Message-ID: <LRKtgfbpeUpRN5o7XLDKMRC1yIjCj10shl0EjXyvhvc=.da35247c-9a66-4a12-93f9-48c3e6c0b44f@github.com>

On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify benchmark
>  - Add benchmark

test/micro/org/openjdk/bench/java/time/ZoneOffsetBench.java line 66:

> 64:         for (int s : CACHED_SECONDS) {
> 65:             ZoneOffset zo = ZoneOffset.ofTotalSeconds(s);
> 66:             sum += zo.getTotalSeconds();

I think we should feed the value of `zo.getTotalSeconds()` into Blackhole, see https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_34_SafeLooping.java#L128

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Wed Feb  1 20:22:49 2023
From: duke at openjdk.org (cheenar)
Date: Wed, 1 Feb 2023 20:22:49 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
Message-ID: <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>

On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify benchmark
>  - Add benchmark

test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:

> 139:     @Test(dataProvider="rules")
> 140:     public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset expectedOffset) {
> 141:         if (expectedOffset == ZoneOffset.UTC)

Extremely minor but why not wrap if with `{}` for improved readability here with the comment

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Wed Feb  1 20:22:51 2023
From: duke at openjdk.org (cheenar)
Date: Wed, 1 Feb 2023 20:22:51 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
 <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>
Message-ID: <4H30se4qw_TKSWrvInldU08F3KKcHmAPPSSuWc9kXYY=.6e30a782-6617-43f9-83d2-8237d5389b85@github.com>

On Wed, 1 Feb 2023 20:16:56 GMT, cheenar <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify benchmark
>>  - Add benchmark
>
> test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:
> 
>> 139:     @Test(dataProvider="rules")
>> 140:     public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset expectedOffset) {
>> 141:         if (expectedOffset == ZoneOffset.UTC)
> 
> Extremely minor but why not wrap if with `{}` for improved readability here with the comment

Same [here](https://github.com/openjdk/jdk/pull/12346/commits/ec49ca3bc03d2e97fa0429c84290923066667871?diff=unified&w=0#diff-9e5aa282dc2d02c31e1d7c5ec8196a1d3d23c06e471d5114d0bd0c78ee4fe5f6R433) although it feels much more dangerous than the test!

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Thu Feb  2 09:29:59 2023
From: duke at openjdk.org (j3graham)
Date: Thu, 2 Feb 2023 09:29:59 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
 <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>
Message-ID: <1JFNX-OhKD3tX8MPVdvQ6WEdsdrdId1C7VJshazArZU=.52bfd266-dede-4362-b41d-38e535d53aa5@github.com>

On Wed, 1 Feb 2023 11:37:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/ZoneOffset.java line 147:
>> 
>>> 145: 
>>> 146:     /** Cache of time-zone offset by offset in seconds [-18h, +18h] for each even quarter of an hour. */
>>> 147:     private static final AtomicReferenceArray<ZoneOffset> SECONDS_CACHE = new AtomicReferenceArray<>(MAX_SECONDS_CACHE_SLOT * 2 + 1);
>> 
>> Can we use regular array instead?
>
> We can but that entails special handling to ensure thread-safety. I will provide such a solution. Thanks.

If you need the thread-safety, perhaps sticking with `AtomicReferenceArray` is a simpler solution than the regular array one.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From rgiulietti at openjdk.org  Thu Feb  2 09:46:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 Feb 2023 09:46:34 GMT
Subject: <i18n dev> RFR: 8300869: Make use of the
 Double.toString(double) algorithm in java.util.Formatter [v8]
In-Reply-To: <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
Message-ID: <R6iJ4b41C83kt2QxS-M8d3r5orriF6Lx4lA-OjzqHYM=.6c2e7a4b-e4ff-4d34-a8a5-e6ef6c5ea617@github.com>

On Wed, 1 Feb 2023 10:26:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

Anyone from **i18n** wants to review before integration?

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From scolebourne at openjdk.org  Thu Feb  2 10:55:25 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Thu, 2 Feb 2023 10:55:25 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v4]
In-Reply-To: <4H30se4qw_TKSWrvInldU08F3KKcHmAPPSSuWc9kXYY=.6e30a782-6617-43f9-83d2-8237d5389b85@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
 <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>
 <4H30se4qw_TKSWrvInldU08F3KKcHmAPPSSuWc9kXYY=.6e30a782-6617-43f9-83d2-8237d5389b85@github.com>
Message-ID: <SkxxZJGo3o7KCmwVIQE2qghuPKx8mbLFhTM3sdtCalo=.717fe5a3-5441-4001-80dd-cd3c18e6a89d@github.com>

On Wed, 1 Feb 2023 20:19:20 GMT, cheenar <duke at openjdk.org> wrote:

>> test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:
>> 
>>> 139:     @Test(dataProvider="rules")
>>> 140:     public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset expectedOffset) {
>>> 141:         if (expectedOffset == ZoneOffset.UTC)
>> 
>> Extremely minor but why not wrap if with `{}` for improved readability here with the comment
>
> Same [here](https://github.com/openjdk/jdk/pull/12346/commits/ec49ca3bc03d2e97fa0429c84290923066667871?diff=unified&w=0#diff-9e5aa282dc2d02c31e1d7c5ec8196a1d3d23c06e471d5114d0bd0c78ee4fe5f6R433) although it feels much more dangerous than the test!

Yes, please always wrap with `{}` in java.time.*

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Thu Feb  2 15:13:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:13:08 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v5]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <Q_ZRnNTLyg5j6ca5K-fC9yXiNjXyCkHGBbLj42mqBco=.166a063f-5093-46c2-afed-5e5e707fa367@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add brackets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/562885c7..48438fd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Thu Feb  2 15:13:11 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:13:11 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v5]
In-Reply-To: <1JFNX-OhKD3tX8MPVdvQ6WEdsdrdId1C7VJshazArZU=.52bfd266-dede-4362-b41d-38e535d53aa5@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
 <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>
 <1JFNX-OhKD3tX8MPVdvQ6WEdsdrdId1C7VJshazArZU=.52bfd266-dede-4362-b41d-38e535d53aa5@github.com>
Message-ID: <J95ufZAPHLSvwUCMyp4uAFj8saTr965SG92mw10NuFM=.4259506d-bc11-416f-b064-8cd23cf31d0a@github.com>

On Thu, 2 Feb 2023 09:26:55 GMT, j3graham <duke at openjdk.org> wrote:

>> We can but that entails special handling to ensure thread-safety. I will provide such a solution. Thanks.
>
> If you need the thread-safety, perhaps sticking with `AtomicReferenceArray` is a simpler solution than the regular array one.

As I used a regular array, I realized I could provide better performance with not much added complexity. See the use of `@Stable` for the components in the array.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Thu Feb  2 15:44:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:44:54 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v6]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/48438fd8..1cd2b406

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=04-05

  Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Thu Feb  2 16:23:55 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 16:23:55 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v6]
In-Reply-To: <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
Message-ID: <SJRHEgWT3V7Qun7tbzqhL1XSzU_H55dp6RkVoDtLmDo=.0e2b6336-897b-4b3d-88cb-2d47c2c9fdc1@github.com>

On Thu, 2 Feb 2023 15:44:54 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix benchmark

Updated figures with the new benchmark:


Baseline
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  887.478 ?(99.9%) 10.206 ns/op [Average]
  (min, avg, max) = (876.206, 887.478, 906.754), stdev = 9.547
  CI (99.9%): [877.271, 897.684] (assumes normal distribution)


Patch
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  252.646 ?(99.9%) 2.794 ns/op [Average]
  (min, avg, max) = (250.451, 252.646, 258.890), stdev = 2.614
  CI (99.9%): [249.851, 255.440] (assumes normal distribution)



JDK 20 - Baseline (JDK 21 before patch)
JDK 21 - Patch

![image](https://user-images.githubusercontent.com/7457876/216381349-38318d43-a9f3-44f8-9019-293ddd7bf3e2.png)

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From naoto at openjdk.org  Thu Feb  2 17:50:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Feb 2023 17:50:28 GMT
Subject: <i18n dev> RFR: 8300869: Make use of the
 Double.toString(double) algorithm in java.util.Formatter [v8]
In-Reply-To: <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
Message-ID: <yaW9YMxSo_PEaeRilctDOzD9Tg23ei3p3cO7jJkKJ60=.ec1958a8-4946-4de3-9ae2-4a05ef7d03da@github.com>

On Wed, 1 Feb 2023 10:26:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

I skimmed through the changes, and see no problem wrt the i18n area.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12259

From rgiulietti at openjdk.org  Thu Feb  2 19:14:35 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 Feb 2023 19:14:35 GMT
Subject: <i18n dev> Integrated: 8300869: Make use of the
 Double.toString(double) algorithm in java.util.Formatter
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <XnJFbZ_uc73ulODZfg2QvWzvb5yBenqA1tSq4M_PSRA=.8f0de484-3ec4-4940-b4f8-b358de3547d2@github.com>

On Fri, 27 Jan 2023 16:02:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

This pull request has now been integrated.

Changeset: f696785f
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f696785fd3bc5b27c06260088a2e0ce520e12142
Stats:     936 lines in 11 files changed: 524 ins; 372 del; 40 mod

8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

Reviewed-by: darcy, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12259

From rriggs at openjdk.org  Fri Feb  3 15:47:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Feb 2023 15:47:07 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v6]
In-Reply-To: <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
Message-ID: <3NLsh7ML4B9x-YSlpvJjfFPCNIS5ZCpeGisUHgmTF_k=.f6cea935-ee7d-4cac-ac6d-03178f0dfd8b@github.com>

On Thu, 2 Feb 2023 15:44:54 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix benchmark

Is this added complexity and startup time (VarHandle) worth it? 
Will normal usage be noticed by typical applications?(Microbenchmark not withstanding).

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From psadhukhan at openjdk.org  Mon Feb  6 08:54:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 08:54:00 GMT
Subject: <i18n dev> Integrated: 4934362: see also refers to self
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <y-sB-jEqGt6lG-eT_lxmMHifSFniLoI779Xs3QHq8sg=.4a3717b6-8a8c-4827-80b8-7071aa2703e3@github.com>

On Tue, 3 Jan 2023 06:00:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

This pull request has now been integrated.

Changeset: ab528ce3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab528ce3cd4bb75a00f5eaadae1f5e45d26712b5
Stats:     27 lines in 10 files changed: 4 ins; 4 del; 19 mod

4934362: see also refers to self

Reviewed-by: prr, serb, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/11820

From pminborg at openjdk.org  Thu Feb  9 13:39:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 13:39:20 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v7]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <wHIb6FlXPGwkt5rdXpUGzDT6OUAqgeJc6twV6PFZ65I=.b2fbaa37-a328-4930-9df5-94f2d832c83e@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add a generic LazyReferenceArray

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/1cd2b406..b89a9aae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=05-06

  Stats: 305 lines in 4 files changed: 275 ins; 19 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From pminborg at openjdk.org  Thu Feb  9 13:46:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 13:46:14 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>

> `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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unused setup method
 - Rename method in test
 - Add copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/b89a9aae..29674b14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=06-07

  Stats: 32 lines in 3 files changed: 23 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From jlaskey at openjdk.org  Fri Feb 10 13:37:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 13:37:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v35]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <qigcd9_Ho_hqmU70v4acg_P88mhLEFg3F95h8YcLEOM=.0fc23f0f-9fbb-4533-a25c-a26e9d3b9a07@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - ... and 40 more: https://git.openjdk.org/jdk/compare/c8ace482...264120a9

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 14:27:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 14:27:17 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v36]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <c3fzYf65-ppnmsSbC41mQMcksftq44h6USI6Jio0KSI=.2ba0037e-8a70-4420-8810-606b823e40bd@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Bring up to date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/264120a9..665cded9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34-35

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:07:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:07:24 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v37]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3Cffq9T2VOO7KsFUbANnyixAkxi4Ztlojk9voEvmF1I=.2ed8c2bf-e704-4661-9185-102ac3f15e7a@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/665cded9..8f5ad0a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=35-36

  Stats: 65 lines in 6 files changed: 55 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:09:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:09:18 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v38]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eezyAvzaM0LdNnfM45CuWMrKf7UHrz2pihbMsQeGL3Q=.9ae6c576-ddcb-4129-ab33-2019ebbadbf3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:

 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - ... and 43 more: https://git.openjdk.org/jdk/compare/4539899c...5fab46c1

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37
  Stats: 9576 lines in 81 files changed: 9411 ins; 28 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:32:00 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:32:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v39]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <tspvAWdHSt6tqlq1TtiLVEO2YywIAJaJWd19gMYsIm4=.6cf6fe32-6d09-46c9-af60-fb334f6cfdb7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Minor correction to javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5fab46c1..5a031bda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37-38

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From rriggs at openjdk.org  Fri Feb 10 21:21:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Feb 2023 21:21:29 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <w4WE_O-wVPplgXgj6hKwPedR7OAMqvjN1mqORLTB4wE=.73d2df75-4216-4128-9db1-d08b4bd9c6a9@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Another musing related to ZoneOffset; it would be desirable if ZoneOffset was a value class (forward looking to the Valhalla project) for performance reasons, meaning immutable and without identity.
Currently, it is "value-based", intending to be immutable, but it has a mutable field that caches the ZoneRules.
At some point, it may be desirable to refactor the implementation to avoid the mutable field.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From jlaskey at openjdk.org  Sat Feb 11 17:49:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 11 Feb 2023 17:49:49 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v40]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <rQog4uNSJmI3BjY7WzAKDkZPttL5RWlJDPPcKwec9aE=.3d2799ca-a8d2-4401-9b05-e6560da18cac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - ... and 45 more: https://git.openjdk.org/jdk/compare/6f9f2b5d...95d219af

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=39
  Stats: 9492 lines in 81 files changed: 9394 ins; 28 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jpai at openjdk.org  Fri Feb 17 12:03:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Feb 2023 12:03:54 GMT
Subject: <i18n dev> RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
Message-ID: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>

Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.

There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.

I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.

tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

-------------

Commit messages:
 - 8302664: Fix several incorrect usages of Preconditions.checkFromIndexSize

Changes: https://git.openjdk.org/jdk/pull/12595/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12595&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302664
  Stats: 19 lines in 8 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12595.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12595/head:pull/12595

PR: https://git.openjdk.org/jdk/pull/12595

From djelinski at openjdk.org  Fri Feb 17 12:23:24 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 17 Feb 2023 12:23:24 GMT
Subject: <i18n dev> RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <AdJx5eUj5xdo9pNnxZuGFtNqM8wRt3WM56jTID-vQGw=.afdc7c0c-9ec3-46aa-81c7-49113b2d8ec2@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

As far as I could tell, this only changes the generated exception message. The condition is (off+len<=size), so the exception will be thrown on the same input as before.

LGTM.

-------------

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/12595

From dfuchs at openjdk.org  Fri Feb 17 13:12:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 Feb 2023 13:12:50 GMT
Subject: <i18n dev> RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <Z7g4goLvmpP3PhLI8bwd189nEwQwR1ZkwjKcluw0JrE=.ac578c4e-0d64-4ae6-8c98-ea59e2a65806@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

As Daniel noted the computation is symmetrical which explains why it worked. But passing inverted parameters was confusing. LGTM2.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12595

From alanb at openjdk.org  Fri Feb 17 13:38:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Feb 2023 13:38:27 GMT
Subject: <i18n dev> RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <Qxe0NasER1twnBSN6DAT8iTPLwxan0fgXsawuXLYIas=.7949dde1-2510-45b1-8dc8-0f788fb7a4df@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

It's easy to get the parameters wrong to these methods but if the fromIndex and size are mixed up then it should just impact the exception message.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12595

From jpai at openjdk.org  Sat Feb 18 00:51:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Feb 2023 00:51:35 GMT
Subject: <i18n dev> RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <H-2SYODzWZY9zA0g101VToxV6GAWAZ4VKm0wJO3Iruc=.4aa395cf-6b1f-4e2f-ae82-bcc290e360e2@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

Thank you all for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/12595

From jpai at openjdk.org  Sat Feb 18 00:51:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Feb 2023 00:51:35 GMT
Subject: <i18n dev> Integrated: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <UqsmHymQ1KB9QVRvD26XVvjy0UaU_JC05dTpgadTGPo=.29800085-8698-46ca-8d43-91ad6e076b9e@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

This pull request has now been integrated.

Changeset: 43cf8b3d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43cf8b3d8067bc7128c98f86d5f8b6fa8bbed80e
Stats:     19 lines in 8 files changed: 0 ins; 0 del; 19 mod

8302664: Fix several incorrect usages of Preconditions.checkFromIndexSize

Reviewed-by: djelinski, dfuchs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12595

From tvaleev at openjdk.org  Sat Feb 18 10:58:10 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 18 Feb 2023 10:58:10 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core libraries
Message-ID: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>

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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

-------------

Commit messages:
 - 8302815 Use new Math.clamp method in core libraries

Changes: https://git.openjdk.org/jdk/pull/12633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302815
  Stats: 41 lines in 12 files changed: 0 ins; 8 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From tvaleev at openjdk.org  Sat Feb 18 21:40:08 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 18 Feb 2023 21:40:08 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v2]
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>

> 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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12633/files
  - new: https://git.openjdk.org/jdk/pull/12633/files/3f3618ae..be13683b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From duke at openjdk.org  Sat Feb 18 22:25:09 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 18 Feb 2023 22:25:09 GMT
Subject: <i18n dev> RFR: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
Message-ID: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>

Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.

Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

-------------

Commit messages:
 - Make isInc private
 - awt.image.incrementaldraw can use Boolean.parseBoolean() to parse the system property

Changes: https://git.openjdk.org/jdk/pull/12639/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302813
  Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12639.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12639/head:pull/12639

PR: https://git.openjdk.org/jdk/pull/12639

From alanb at openjdk.org  Sun Feb 19 08:57:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Feb 2023 08:57:22 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v2]
In-Reply-To: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
Message-ID: <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>

On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

Yes, the jrt file system provider is compiled --release 8 to create lib/jrt-fs.jar. That's the plumbing needed to allow IDEs/tools running on JDK 8 access the contents of a target run-time image as a file system.

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From duke at openjdk.org  Sun Feb 19 23:59:13 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 19 Feb 2023 23:59:13 GMT
Subject: <i18n dev> RFR: 8026369: javac potentially ambiguous overload
 warning needs an improved scheme
Message-ID: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>

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 forEachRemaining(Consumer<? super Integer> action);
void forEachRemaining(IntConsumer action);

Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:

    spliterator.forEachRemaining(x -> { ... });

That code won't compile; instead, you'll get this error:

Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
        spliterator.forEachRemaining(x -> { });
                   ^
  both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match


The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:

interface ConsumerOfInteger {
    void foo(Consumer<Integer> c);
}

interface IntegerConsumer {
    void foo(IntConsumer c);
}

// We should get a warning here...
interface Test extends ConsumerOfInteger, IntegerConsumer {
}


The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.

To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.

So we generate the warning when there are two methods m1 and m2 in a class C such that:

* m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
* There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
* We haven't already generated a warning for either m1 or m2 in class C

If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.

I noticed a couple of other minor bugs; these are also being fixed here:

(1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:

interface Upper<T> {
    void foo(T c);
}

interface Lower extends Upper<IntConsumer> {
    void foo(Consumer<Integer> c);
}

Currently, the error is reported as:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper

Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper


(2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.

As a result, for a class like the one below, the compiler was only generating one warning instead of three:

public interface SuperIface {
    void foo(Consumer<Integer> c);
}

public interface I1 extends SuperIface { 
    void foo(IntConsumer c);        // warning was generated here
}   

public interface I2 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   

public interface I3 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   


With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.

Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

-------------

Commit messages:
 - Fix incomplete detection of potentially ambiguous method declarations.

Changes: https://git.openjdk.org/jdk/pull/12645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8026369
  Stats: 356 lines in 18 files changed: 280 ins; 36 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From pminborg at openjdk.org  Mon Feb 20 09:59:27 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Feb 2023 09:59:27 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <q5aVKbC-QUUMAC4Z-iiydJiANTmHgV5kkDfgILmqnu8=.04588ea4-0627-4b48-ade0-3c66b1fdef4d@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> 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 `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Other potential candidates for using `LazyReferenceArray`:

* java.nio.charset.CoderResult
* ZoneRule
* Locale
* sun.font.FileFontStrike, PhysicalStrike
* sun.security.Token
* sun.security.provider.ParameterCache
* sun.security.ssl.SSLSessionContextImpl
* sun.util.locale.provider.LocaleProviderAdapter

NOTE: The one mentioned above are candidates and further investigation is needed to see if they are actually a fit.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Mon Feb 20 13:19:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:19:16 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
Message-ID: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>

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`

To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.

Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

-------------

Commit messages:
 - Exhaustive verification needs to cover the case b1 == b2
 - Move multiplication exclusion to the lat1 range branch
 - Speed up StringLatin1.regionMatchesCI by applying the 'oldest ASCII trick in the book'

Changes: https://git.openjdk.org/jdk/pull/12632/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302871
  Stats: 158 lines in 4 files changed: 148 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:19:17 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <JWx0OiFib9dJQhDyAqVnz6ErMrDGaLmGK0Fp9nUI25E=.6d174a6f-7eee-4bb7-809b-8438dad22b52@github.com>

On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Benchmark results:

Baseline:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  2216.525 ? 79.626  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     5.049 ?  0.044  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   708.977 ? 19.381  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.726 ?  0.036  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2134.499 ? 23.064  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.227 ?  0.070  ns/op


Patch:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   809.729 ? 40.257  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.334 ?  0.031  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   370.814 ? 39.790  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.766 ?  0.072  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1247.979 ?  7.826  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.819 ?  0.026  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:20 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:19:20 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>
Message-ID: <_mGSxILQqWkEQ4oxqilr8A5FZ2eeu_3A34dZpjduXo0=.55145913-1c2f-4700-9713-81b09d387440@github.com>

On Sat, 18 Feb 2023 19:04:24 GMT, David Schlosnagle <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> 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, excl. multiplication
>> 181:                  && U == (b2 & 0xDF); // b2 has same uppercase
> 
> I'm curious if the order of comparisons could alter performance to a small degree. For example, it might be interesting to compare various permutations like below to short circuit reject unequal uppercased b2
> 
> Suggestion:
> 
>          // uppercase b1 using 'the oldest ASCII trick in the book'
>          int U = b1 & 0xDF;
>          return (U == (b2 & 0xDF))
>              && ((U >= 'A' && U <= 'Z') // In range A-Z
>                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication

Yeah, as you noticed this code is tricky and sensitive to the order of operations. I did some quite extensive exploration before ending on the current structure. This particular one seems to improve rejection somewhat at the cost of matches.

Since rejection is relatively speaking already very fast, I think we should favour fast matching here.

Results:


enchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   917.796 ? 20.285  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.367 ?  0.348  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   399.656 ? 10.703  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.361 ?  0.664  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1384.443 ? 22.199  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.119 ?  0.451  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:20 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 20 Feb 2023 13:19:20 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>

On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

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, excl. multiplication
> 181:                  && U == (b2 & 0xDF); // b2 has same uppercase

I'm curious if the order of comparisons could alter performance to a small degree. For example, it might be interesting to compare various permutations like below to short circuit reject unequal uppercased b2

Suggestion:

         // uppercase b1 using 'the oldest ASCII trick in the book'
         int U = b1 & 0xDF;
         return (U == (b2 & 0xDF))
             && ((U >= 'A' && U <= 'Z') // In range A-Z
                 || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:21 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 20 Feb 2023 13:19:21 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <_mGSxILQqWkEQ4oxqilr8A5FZ2eeu_3A34dZpjduXo0=.55145913-1c2f-4700-9713-81b09d387440@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>
 <_mGSxILQqWkEQ4oxqilr8A5FZ2eeu_3A34dZpjduXo0=.55145913-1c2f-4700-9713-81b09d387440@github.com>
Message-ID: <3ybXhT9NAtZLE4znb2PntN0OlC_bB78F7hC3bRai3a8=.667ebc8b-556c-4725-8251-0606f9f32952@github.com>

On Sat, 18 Feb 2023 19:45:34 GMT, Eirik Bjorsnos <duke at openjdk.org> 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, excl. multiplication
>>> 181:                  && U == (b2 & 0xDF); // b2 has same uppercase
>> 
>> I'm curious if the order of comparisons could alter performance to a small degree. For example, it might be interesting to compare various permutations like below to short circuit reject unequal uppercased b2
>> 
>> Suggestion:
>> 
>>          // uppercase b1 using 'the oldest ASCII trick in the book'
>>          int U = b1 & 0xDF;
>>          return (U == (b2 & 0xDF))
>>              && ((U >= 'A' && U <= 'Z') // In range A-Z
>>                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>
> Yeah, as you noticed this code is tricky and sensitive to the order of operations. I did some quite extensive exploration before ending on the current structure. This particular one seems to improve rejection somewhat at the cost of matches.
> 
> Since rejection is relatively speaking already very fast, I think we should favour fast matching here.
> 
> Results:
> 
> 
> enchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   917.796 ? 20.285  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.367 ?  0.348  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   399.656 ? 10.703  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.361 ?  0.664  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1384.443 ? 22.199  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.119 ?  0.451  ns/op

Thanks for confirming

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:39:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:39:09 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v2]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <ilxA1VwMFjFLVPzNOLPMeAW7XSHxtbl-CQTsNI9MKBs=.329eca84-6e35-476e-894e-3e94fb7aab43@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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 since the last revision:

 - Align whitespace to make example strings easier to read
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Exhaustive verification needs to cover the case b1 == b2
 - Move multiplication exclusion to the lat1 range branch
 - Speed up StringLatin1.regionMatchesCI by applying the 'oldest ASCII trick in the book'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/a583bcd6..59c42298

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=00-01

  Stats: 57495 lines in 1316 files changed: 24512 ins; 15682 del; 17301 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:52:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:52:18 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v3]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <KNC8BUrQ-eJazbuAC2m5Rh4SmmBFTA_WILTgGtlMGZo=.d6b8ab36-9d9b-4313-a348-14332286fcf7@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Add clarifying comments and use more descriptive variable names in the latin1 verification EqualsIgnoreCase test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/59c42298..84517102

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=01-02

  Stats: 16 lines in 1 file changed: 5 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 14:45:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:45:09 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v4]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

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 for JDK-8302877

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/84517102..03d3e2cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 14:47:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:47:33 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions
Message-ID: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>

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 points which uppercase out of latin1).

To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.

The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.

Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

-------------

Commit messages:
 - Add @bug tag to test
 - Improved whitespace alignment for Param and switch values
 - Correct spelling for "exhaustive"
 - Prefer the term "case conversion" over ""case folding". Refer to 0xB5 as 'Micro Sign' ("Mu" is the Unicode code point it uppercases to)
 - Improve comments for the two special-cased uppercase code points 'Micro Sign' and 'y with Diaeresis'
 - Adjust whitespace
 - Speed up Character.toUpperCase and Character.toLowerCase by applying the 'oldest ASCII trick in the book'

Changes: https://git.openjdk.org/jdk/pull/12623/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302877
  Stats: 164 lines in 3 files changed: 143 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12623.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12623/head:pull/12623

PR: https://git.openjdk.org/jdk/pull/12623

From naoto at openjdk.org  Mon Feb 20 14:47:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 Feb 2023 14:47:36 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>

On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Looks good to me. I'd rather not use "case folding", as to me it implies "normalizing" but this is simply lowercasing/uppercasing.

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"?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Mon Feb 20 14:47:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:47:39 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
Message-ID: <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>

On Sat, 18 Feb 2023 00:57:14 GMT, Naoto Sato <naoto at openjdk.org> 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/Character/Latin1CaseFolding.java line 31:
> 
>> 29: /**
>> 30:  * @test
>> 31:  * @summary Provides exchaustive verification of Character.toUpperCase and Character.toLowerCase
> 
> typo: "exhaustive"?

I did an 'exchaustive' search for 'exchaustive' across the code base and found  two comments in `LocaleData` and `LocaleData.cldr` in `jdk/test/jdk/sun/text/resources`.

Would you like me to update these as well while we're here, or should we avoid getting out scope for this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Mon Feb 20 14:47:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:47:37 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <hktDVAh_HYJ3M0K4HuX8vQYrdtlufQ6AssH3dOLvx60=.93ed8116-14a8-4ada-a5ca-983ee5e1d838@github.com>

On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Benchmark results:

Baseline:


Benchmark                                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.Latin1CaseConversion.toLowerCase          low  avgt   15  1.267 ? 0.013  ns/op
Characters.Latin1CaseConversion.toLowerCase            A  avgt   15  1.657 ? 0.011  ns/op
Characters.Latin1CaseConversion.toLowerCase            a  avgt   15  1.258 ? 0.005  ns/op
Characters.Latin1CaseConversion.toLowerCase      A-grave  avgt   15  1.656 ? 0.011  ns/op
Characters.Latin1CaseConversion.toLowerCase      a-grave  avgt   15  1.270 ? 0.023  ns/op
Characters.Latin1CaseConversion.toLowerCase           mu  avgt   15  1.261 ? 0.006  ns/op
Characters.Latin1CaseConversion.toLowerCase           yD  avgt   15  1.260 ? 0.005  ns/op
Characters.Latin1CaseConversion.toUpperCase          low  avgt   15  1.284 ? 0.043  ns/op
Characters.Latin1CaseConversion.toUpperCase            A  avgt   15  1.264 ? 0.008  ns/op
Characters.Latin1CaseConversion.toUpperCase            a  avgt   15  1.818 ? 0.016  ns/op
Characters.Latin1CaseConversion.toUpperCase      A-grave  avgt   15  1.261 ? 0.015  ns/op
Characters.Latin1CaseConversion.toUpperCase      a-grave  avgt   15  1.822 ? 0.013  ns/op
Characters.Latin1CaseConversion.toUpperCase           mu  avgt   15  1.823 ? 0.006  ns/op
Characters.Latin1CaseConversion.toUpperCase           yD  avgt   15  1.822 ? 0.008  ns/op


PR:


Benchmark                                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.Latin1CaseConversion.toLowerCase          low  avgt   15  0.878 ? 0.005  ns/op
Characters.Latin1CaseConversion.toLowerCase            A  avgt   15  1.038 ? 0.009  ns/op
Characters.Latin1CaseConversion.toLowerCase            a  avgt   15  1.036 ? 0.007  ns/op
Characters.Latin1CaseConversion.toLowerCase      A-grave  avgt   15  1.357 ? 0.015  ns/op
Characters.Latin1CaseConversion.toLowerCase      a-grave  avgt   15  1.352 ? 0.003  ns/op
Characters.Latin1CaseConversion.toLowerCase           mu  avgt   15  1.273 ? 0.002  ns/op
Characters.Latin1CaseConversion.toLowerCase           yD  avgt   15  1.352 ? 0.004  ns/op
Characters.Latin1CaseConversion.toUpperCase          low  avgt   15  0.880 ? 0.013  ns/op
Characters.Latin1CaseConversion.toUpperCase            A  avgt   15  0.920 ? 0.071  ns/op
Characters.Latin1CaseConversion.toUpperCase            a  avgt   15  1.055 ? 0.013  ns/op
Characters.Latin1CaseConversion.toUpperCase      A-grave  avgt   15  1.394 ? 0.010  ns/op
Characters.Latin1CaseConversion.toUpperCase      a-grave  avgt   15  1.391 ? 0.009  ns/op
Characters.Latin1CaseConversion.toUpperCase           mu  avgt   15  1.597 ? 0.021  ns/op
Characters.Latin1CaseConversion.toUpperCase           yD  avgt   15  1.354 ? 0.003  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From redestad at openjdk.org  Mon Feb 20 15:43:28 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 15:43:28 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v4]
In-Reply-To: <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
Message-ID: <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>

On Mon, 20 Feb 2023 14:45:09 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> 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 for JDK-8302877

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 equalsIgnoreCase(byte b1, byte b2) {

Perhaps put this in `CharacterDataLatin1`, keeping it close to toLowerCase/toUpperCase that you're changing to use similar logic with #12623 

If you apply #12623 first - how much difference does this make on the micro you're adding with this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 16:19:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 16:19:27 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v4]
In-Reply-To: <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
 <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
Message-ID: <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>

On Mon, 20 Feb 2023 15:40:09 GMT, Claes Redestad <redestad at openjdk.org> 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 for JDK-8302877
>
> 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 equalsIgnoreCase(byte b1, byte b2) {
> 
> Perhaps put this in `CharacterDataLatin1`, keeping it close to toLowerCase/toUpperCase that you're changing to use similar logic with #12623 
> 
> If you apply #12623 first - how much difference does this make on the micro you're adding with this PR?

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/toLowerCase only:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  1310.582 ? 84.777  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.547 ?  0.545  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   686.947 ? 11.850  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.836 ?  0.634  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2107.219 ? 17.662  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.924 ?  0.829  ns/op


CharacterDataLatin1.equalsIgnoreCase:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   742.467 ? 34.490  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.960 ?  0.046  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   361.158 ? 37.096  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.039 ?  0.521  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1158.091 ? 41.617  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.358 ?  0.123  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From redestad at openjdk.org  Mon Feb 20 16:26:26 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 16:26:26 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v4]
In-Reply-To: <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
 <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
 <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>
Message-ID: <pXrtSJWYC3DHlIw3jxQeJofD1IJf0J2jR8swTk9qGpo=.345d231e-e994-4518-8ea5-5b2bd920e523@github.com>

On Mon, 20 Feb 2023 16:16:45 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 equalsIgnoreCase(byte b1, byte b2) {
>> 
>> Perhaps put this in `CharacterDataLatin1`, keeping it close to toLowerCase/toUpperCase that you're changing to use similar logic with #12623 
>> 
>> If you apply #12623 first - how much difference does this make on the micro you're adding with this PR?
>
> 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/toLowerCase only:
> 
> 
> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  1310.582 ? 84.777  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.547 ?  0.545  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   686.947 ? 11.850  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.836 ?  0.634  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2107.219 ? 17.662  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.924 ?  0.829  ns/op
> 
> 
> CharacterDataLatin1.equalsIgnoreCase:
> 
> 
> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   742.467 ? 34.490  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.960 ?  0.046  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   361.158 ? 37.096  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.039 ?  0.521  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1158.091 ? 41.617  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.358 ?  0.123  ns/op

Oops, I lost context and thought this was in `StringLatin1`.

Thanks for running the numbers with #12623. Looks like you're getting big enough of an improvement on top.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 16:30:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 16:30:29 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v4]
In-Reply-To: <pXrtSJWYC3DHlIw3jxQeJofD1IJf0J2jR8swTk9qGpo=.345d231e-e994-4518-8ea5-5b2bd920e523@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
 <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
 <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>
 <pXrtSJWYC3DHlIw3jxQeJofD1IJf0J2jR8swTk9qGpo=.345d231e-e994-4518-8ea5-5b2bd920e523@github.com>
Message-ID: <L-JgKLbOarQM_S3KYtLffTDBJXeuLkNDR_6EGqHdK4g=.f137d2f0-c47c-4c2a-8333-304053c4af2e@github.com>

On Mon, 20 Feb 2023 16:23:32 GMT, Claes Redestad <redestad at openjdk.org> 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/toLowerCase only:
>> 
>> 
>> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
>> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  1310.582 ? 84.777  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.547 ?  0.545  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   686.947 ? 11.850  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.836 ?  0.634  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2107.219 ? 17.662  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.924 ?  0.829  ns/op
>> 
>> 
>> CharacterDataLatin1.equalsIgnoreCase:
>> 
>> 
>> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
>> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   742.467 ? 34.490  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.960 ?  0.046  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   361.158 ? 37.096  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.039 ?  0.521  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1158.091 ? 41.617  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.358 ?  0.123  ns/op
>
> Oops, I lost context and thought this was in `StringLatin1`.
> 
> Thanks for running the numbers with #12623. Looks like you're getting big enough of an improvement on top.

Yes, seems `equalsIgnoreCase` carries its weight.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Mon Feb 20 17:40:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 17:40:26 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v2]
In-Reply-To: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
Message-ID: <x4wYWxXT9oJFQpk4omqHYAS4Iodmz1xFzqP7J9jMBIk=.e747a1e9-c0a2-4de0-b75e-dd05ce3652db@github.com>

On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> 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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

I skimmed through the usages and they look okay. I didn't spot anywhere that it differs to the existing clamping. This is the first update in 2023 for some of these files so I assume you'll bump the copyright year before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12633

From duke at openjdk.org  Mon Feb 20 23:55:24 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 23:55:24 GMT
Subject: <i18n dev> RFR: 8026369: javac potentially ambiguous overload
 warning needs an improved scheme
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>

On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs <duke at openjdk.org> 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 `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

In the `AWTEventMulticaster` class(es), which interfaces are causing the ambiguity?

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From naoto at openjdk.org  Tue Feb 21 00:17:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 00:17:25 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
 <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>
Message-ID: <UzZau1cG5pNwApw4QrS4HIWlQDXgj32G617BC_TdYK8=.bb876d03-c466-4dbc-8e3c-d62dc1373aa7@github.com>

On Sat, 18 Feb 2023 06:43:27 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 did an 'exchaustive' search for 'exchaustive' across the code base and found  two comments in `LocaleData` and `LocaleData.cldr` in `jdk/test/jdk/sun/text/resources`.
> 
> Would you like me to update these as well while we're here, or should we avoid getting out scope for this PR?

I'd appreciate it. I don't mind fixing it with this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 06:54:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 06:54:48 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v5]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <dgsG0NP-afd68wkXcdpnIS6lRh21-cF1wDsq9mDGnl4=.daf72737-5155-44ef-a6bd-9122acf0feae@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Spell fix for 'exhaustive' in comments in sun/text/resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/03d3e2cb..5e9927a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 06:58:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 06:58:52 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v6]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <0axKMeojwnFwgufDJPLLALvqougnoM2d5FRMVCxoHtc=.dca5737d-97b4-4f48-84ee-f120e16eb31b@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Spell fix for 'exhaustive' in comments in sun/text/resources"
  
  This reverts commit 5e9927a4b35e157fd3fa72fd2663c8bfbecf32bb.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/5e9927a4..b8139961

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 06:59:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 06:59:47 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>

> 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 points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Spell fix for 'exhaustive' in comments in sun/text/resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12623/files
  - new: https://git.openjdk.org/jdk/pull/12623/files/57a27d39..70c624d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12623.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12623/head:pull/12623

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 08:01:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 08:01:28 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <UzZau1cG5pNwApw4QrS4HIWlQDXgj32G617BC_TdYK8=.bb876d03-c466-4dbc-8e3c-d62dc1373aa7@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
 <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>
 <UzZau1cG5pNwApw4QrS4HIWlQDXgj32G617BC_TdYK8=.bb876d03-c466-4dbc-8e3c-d62dc1373aa7@github.com>
Message-ID: <jZ_2aUBT_oYutGxgiMmh5EMLYWoj-z93VqEsuHS5yQM=.1db513b8-4bf7-466a-a033-c912647b9198@github.com>

On Tue, 21 Feb 2023 00:14:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I did an 'exchaustive' search for 'exchaustive' across the code base and found  two comments in `LocaleData` and `LocaleData.cldr` in `jdk/test/jdk/sun/text/resources`.
>> 
>> Would you like me to update these as well while we're here, or should we avoid getting out scope for this PR?
>
> I'd appreciate it. I don't mind fixing it with this PR.

Thanks Naoto, I have fixed the spelling in these two unrelated files.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 09:37:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 09:37:28 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
Message-ID: <Dc0Aa1UAJeikMEJlfTKSSB1lbBwPY3Bu7b3cSxRkf48=.9e8c2b19-9654-4885-9174-edb852df5e78@github.com>

On Tue, 21 Feb 2023 06:59:47 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spell fix for 'exhaustive' in comments in sun/text/resources

A site note: Early and crude experiements using the Vector API indicate that the 'oldest ASCII trick in the book' vectorizes pretty well.

Here's a benchmark comparing the strings "helloworld" and "HelloWorld" repeated 1024 times, followed by either 'A' or 'B' (to force a an expensive mismatch):


Benchmark                    (size)  Mode  Cnt     Score    Error  Units
EqualsIgnoreCase.scalar        1024  avgt   15  6225.624 ? 89.182  ns/op
EqualsIgnoreCase.vectorized    1024  avgt   15  1246.110 ? 14.767  ns/op


I have the feeling that most case-insensitive comparisons are pretty short, so not sure how useful this is IRL.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 10:03:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 10:03:28 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <Dc0Aa1UAJeikMEJlfTKSSB1lbBwPY3Bu7b3cSxRkf48=.9e8c2b19-9654-4885-9174-edb852df5e78@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
 <Dc0Aa1UAJeikMEJlfTKSSB1lbBwPY3Bu7b3cSxRkf48=.9e8c2b19-9654-4885-9174-edb852df5e78@github.com>
Message-ID: <qWTVI7TOpTidxp-44uAW4EaHNw0DQ2NwQg-T9JCcutY=.7c1ccf20-fef4-4fe8-9731-f60e437e47b3@github.com>

On Tue, 21 Feb 2023 09:33:07 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I have the feeling that most case-insensitive comparisons are pretty short, so not sure how useful this is IRL.

There seems to be a win from strings of size 32 bytes upwards. (That's probably longer than most keys in TreeMaps using String.CASE_INSENSITIVE_ORDER, such as j.n.h.HttpHeaders)


Benchmark                    (size)  Mode  Cnt   Score   Error  Units
EqualsIgnoreCase.scalar          16  avgt    2  20.608          ns/op
EqualsIgnoreCase.scalar          32  avgt    2  36.510          ns/op
EqualsIgnoreCase.vectorized      16  avgt    2  18.601          ns/op
EqualsIgnoreCase.vectorized      32  avgt    2  12.795          ns/op


This is outside scope for this PR, I just wanted to leave a trace of this observation here for future record.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From redestad at openjdk.org  Tue Feb 21 10:40:33 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Feb 2023 10:40:33 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
Message-ID: <vWnEYhacyhcGD-gGaB22K8wLvQU_3ZF9m0cv1IJxdrs=.c0fc41ee-d618-4f97-b3b5-b67b098187df@github.com>

On Tue, 21 Feb 2023 06:59:47 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spell fix for 'exhaustive' in comments in sun/text/resources

Looks good. Some nits inline

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 142:

> 140:         }
> 141:         int l = ch | 0x20; // Lowercase using 'oldest ASCII trick in the book'
> 142:         if ( l <= 'z' // In range a-z

Suggestion:

        if (l <= 'z' // In range a-z

test/micro/org/openjdk/bench/java/lang/Characters.java line 92:

> 90:     @Measurement(iterations = 5, time = 1)
> 91:     @Fork(3)
> 92:     public static class Latin1CaseConversions {

Not sure if qualifying this as "Latin1" is necessary, even though that's what you've focused on for this PR. We could easily add some codePoints outside of the latin1 range (now or later) without changing the test. 

While having a switch with some readable names is a nice touch I think we should additionally allow integer codePoint as-is to keep it in line with the outer class, e.g. `default -> Integer.parseInt(codePoint);`

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 11:12:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:12:18 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>

> 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 points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Allow any integer codePoint by defaulting to Integer.parseInt
 - Rename Latin1CaseConversions to just CaseConversions
 - Remove a whitespace following 'if ('

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12623/files
  - new: https://git.openjdk.org/jdk/pull/12623/files/70c624d7..bff999c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12623.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12623/head:pull/12623

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 11:12:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:12:23 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <vWnEYhacyhcGD-gGaB22K8wLvQU_3ZF9m0cv1IJxdrs=.c0fc41ee-d618-4f97-b3b5-b67b098187df@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
 <vWnEYhacyhcGD-gGaB22K8wLvQU_3ZF9m0cv1IJxdrs=.c0fc41ee-d618-4f97-b3b5-b67b098187df@github.com>
Message-ID: <LXmWyg_KOlELUH8Ca98n3gVZqvIrRQ0fNxhfL19TRwo=.3d3f57a8-6e9a-411a-8ce2-dea7d3417a1a@github.com>

On Tue, 21 Feb 2023 10:29:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spell fix for 'exhaustive' in comments in sun/text/resources
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 142:
> 
>> 140:         }
>> 141:         int l = ch | 0x20; // Lowercase using 'oldest ASCII trick in the book'
>> 142:         if ( l <= 'z' // In range a-z
> 
> Suggestion:
> 
>         if (l <= 'z' // In range a-z

Fixed! (My IDE does not highlight this code, making it a bit harder to spot mistakes like this)

> test/micro/org/openjdk/bench/java/lang/Characters.java line 92:
> 
>> 90:     @Measurement(iterations = 5, time = 1)
>> 91:     @Fork(3)
>> 92:     public static class Latin1CaseConversions {
> 
> Not sure if qualifying this as "Latin1" is necessary, even though that's what you've focused on for this PR. We could easily add some codePoints outside of the latin1 range (now or later) without changing the test. 
> 
> While having a switch with some readable names is a nice touch I think we should additionally allow integer codePoint as-is to keep it in line with the outer class, e.g. `default -> Integer.parseInt(codePoint);`

You are probably right that Latin1 is a bit narrow here, removing the prefix.

I added Integer.parseInt as the default, good idea!

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 11:14:13 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:14:13 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Remove whitespace following '('

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/b8139961..d7b1c164

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 11:22:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:22:33 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <uMH3tqRBRQH_5qCi2Y1iz9gh54_sVw38YbJ5kfbT4vk=.e67ecee7-a713-428a-b87e-9cd67a41dcdd@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

Thanks for your review and JBS juggling, Claes! 

I'll wait for a final word from @naotoj before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From redestad at openjdk.org  Tue Feb 21 11:24:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Feb 2023 11:24:38 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
Message-ID: <lTiIOXTbicgBCTT8VaCf3b7FCI__XUub3O5RCPlEOh8=.2e052c53-7837-4517-b3f3-7b9dce93b8f2@github.com>

On Tue, 21 Feb 2023 11:14:13 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace following '('

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Tue Feb 21 14:30:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 14:30:29 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
Message-ID: <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>

On Tue, 21 Feb 2023 11:14:13 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace following '('

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 163:

> 161:         return mapChar;
> 162:     }
> 163:     /**

I assume you should insert a blank line between the two methods.

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 175:

> 173:          }
> 174:          // uppercase b1 using 'the oldest ASCII trick in the book'
> 175:          int U = b1 & 0xDF;

I'm sure some people reading this comment will wonder which book :-) It might be better to drop that bit and if possible, find a better name for "U" as normally variables start with a lower case.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From naoto at openjdk.org  Tue Feb 21 17:25:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 17:25:28 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <k8qXzZvjzpzAaAZ3clFqtbLroxYT88uJ2YFXC-Lv_t4=.7f278f5a-0873-4cbc-ab27-5b227f7fbed5@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

LGTM. Thanks for the fix!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 18:23:18 2023
From: duke at openjdk.org (Madjosz)
Date: Tue, 21 Feb 2023 18:23:18 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider() twice
 will remove provider
Message-ID: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>

Fixes JDK-8302983 (and duplicate JDK-8302898)

-------------

Commit messages:
 - 8302983: ZoneRulesProvider.registerProvider() twice will remove provider

Changes: https://git.openjdk.org/jdk/pull/12690/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302983
  Stats: 53 lines in 2 files changed: 49 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From jlu at openjdk.org  Tue Feb 21 19:34:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Feb 2023 19:34:11 GMT
Subject: <i18n dev> RFR: 8302512: Update IANA Language Subtag Registry to
 Version 2023-02-14
Message-ID: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>

Incorporate the latest IANA language subtag registry definition (2023-02-14).

-------------

Commit messages:
 - Add missing JBS #s to test header
 - IANA update 2/14/23

Changes: https://git.openjdk.org/jdk/pull/12699/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302512
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12699.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12699/head:pull/12699

PR: https://git.openjdk.org/jdk/pull/12699

From naoto at openjdk.org  Tue Feb 21 19:46:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 19:46:25 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022
Message-ID: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>

Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

-------------

Commit messages:
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - Removed unused annotation
 - Removed null check
 - ... and 4 more: https://git.openjdk.org/jdk/compare/574b48c6...0f3c25ce

Changes: https://git.openjdk.org/jdk/pull/12518/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301119
  Stats: 283 lines in 14 files changed: 129 ins; 41 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Tue Feb 21 20:00:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 20:00:26 GMT
Subject: <i18n dev> RFR: 8302512: Update IANA Language Subtag Registry
 to Version 2023-02-14
In-Reply-To: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
Message-ID: <mvbATd8t4UfqoAaFHmSe_xvNX5lu-1ZlTeaFreD6hnQ=.d97352d2-2f7b-404e-bc26-cba0c40df28d@github.com>

On Tue, 21 Feb 2023 19:26:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Incorporate the latest IANA language subtag registry definition (2023-02-14).

Looks good. Please update the copyright year for the test changes.

test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 29:

> 27:  *      8258795 8267038 8287180 8302512
> 28:  * @summary Checks the IANA language subtag registry data update
> 29:  *          (LSR Revision: 2023-2-14) with Locale and Locale.LanguageRange

Add prepending `0` to the month to keep the YYYY-MM-DD format.

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From jlu at openjdk.org  Tue Feb 21 20:08:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Feb 2023 20:08:41 GMT
Subject: <i18n dev> RFR: 8302512: Update IANA Language Subtag Registry
 to Version 2023-02-14 [v2]
In-Reply-To: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
Message-ID: <M65a9-Cdfh9cNtFyivbLeL2F8982Aha4ecoLJ2XPsoI=.605031d4-80f4-4065-90bc-373f7e5927dd@github.com>

> Incorporate the latest IANA language subtag registry definition (2023-02-14).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Copyright + correct date format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12699/files
  - new: https://git.openjdk.org/jdk/pull/12699/files/2cd597c9..b502f523

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12699&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12699&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12699.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12699/head:pull/12699

PR: https://git.openjdk.org/jdk/pull/12699

From jlu at openjdk.org  Tue Feb 21 20:08:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Feb 2023 20:08:43 GMT
Subject: <i18n dev> RFR: 8302512: Update IANA Language Subtag Registry
 to Version 2023-02-14 [v2]
In-Reply-To: <mvbATd8t4UfqoAaFHmSe_xvNX5lu-1ZlTeaFreD6hnQ=.d97352d2-2f7b-404e-bc26-cba0c40df28d@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
 <mvbATd8t4UfqoAaFHmSe_xvNX5lu-1ZlTeaFreD6hnQ=.d97352d2-2f7b-404e-bc26-cba0c40df28d@github.com>
Message-ID: <H7Jpu4VynPC8L0Xyl61f_fowgR3de5M_z4gJcn5cSKY=.1aed85a8-86fa-4c02-bdf0-5f2b14076ed1@github.com>

On Tue, 21 Feb 2023 19:56:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright + correct date format
>
> test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 29:
> 
>> 27:  *      8258795 8267038 8287180 8302512
>> 28:  * @summary Checks the IANA language subtag registry data update
>> 29:  *          (LSR Revision: 2023-2-14) with Locale and Locale.LanguageRange
> 
> Add prepending `0` to the month to keep the YYYY-MM-DD format.

Thanks for catching, fixed

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From duke at openjdk.org  Tue Feb 21 20:28:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 20:28:30 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
Message-ID: <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>

On Tue, 21 Feb 2023 14:27:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove whitespace following '('
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 175:
> 
>> 173:          }
>> 174:          // uppercase b1 using 'the oldest ASCII trick in the book'
>> 175:          int U = b1 & 0xDF;
> 
> I'm sure some people reading this comment will wonder which book :-) It might be better to drop that bit and if possible, find a better name for "U" as normally variables start with a lower case.

Hi Alan,

I thought I was clever by encoding the 'uppercaseness' in the variable name, but yeah I'll find a better name :)

There is some precedent for using the 'ASCII trick' comment in the JDK.  I found it in ZipFile.isMetaName, which is also where I first learned about this interesting relationship between ASCII (and also latin1) letters.

The comment was first added by Martin Buchholz back in 2016 as part of JDK-8157069, 'Assorted ZipFile improvements'. In 2020, Claes was updating this code and Lance has some input about clarifying the comment. Martin then [chimed in](https://mail.openjdk.org/pipermail/core-libs-dev/2020-May/066363.html) to defend his comment:

> I still like my ancient "ASCII trick" comment.

I think this 'trick', whatever we call it, is sufficiently intricate that it deserves to be called out somehow and that we should not just casually bitmask with these magic constants without any discussion at all. 

An earlier iteration of this PR included a small essay in the javadoc of this method describing the layout and relationship of letters in latin1 and how we can apply that knowledge of the layout to implement the method.

How would you feel about adding that description back to the Javadocs? This would then live close to the similarly implemented toUpperCase and toLowerCase methods currently under review in #12623. 

Here's the updated discussion included in the Javadoc:


    /**
     * Compares two latin1 code points, ignoring case considerations.
     *
     * Implementation note: In ISO/IEC 8859-1, the uppercase and lowercase
     * letters are found in the following code point ranges:
     *
     * 0x41-0x5A: Uppercase ASCII letters: A-Z
     * 0x61-0x7A: Lowercase ASCII letters: a-z
     * 0xC0-0xD6: Uppercase latin1 letters: A-GRAVE - O with Diaeresis
     * 0xD8-0xDE: Uppercase latin1 letters: O with slash - Thorn
     * 0xE0-0xF6: Lowercase latin1 letters: a-grave - o with Diaeresis
     * 0xF8-0xFE: Lowercase latin1 letters: o with slash - thorn
     *
     * While both ASCII letter ranges are contiguous, the latin1 ranges are not:
     *
     * The 'multiplication sign' 0xD7 splits the uppercase range in two.
     * The 'division sign' 0xF7 splits the lowercase range in two.
     *
     * Lowercase letters are found 32 positions (0x20) after their corresponding uppercase letter.
     * The 'division sign' and 'multiplication sign' have the same relative distance.
     *
     * Since 0x20 is a single bit, we can apply the 'oldest ASCII trick in the book' to
     * lowercase any letter by setting the bit:
     *
     * ('C' | 0x20) == 'c'
     *
     * By removing the bit, we can perform the uppercase operation:
     *
     * ('c' & 0xDF) == 'C'
     *
     * Applying this knowledge of the latin1 layout, we can test for equality ignoring case by
     * checking that the code points are either equal, or that one of the code points is a letter
     * which uppercases is the same as the uppercase of the other code point.
     *
     * @param b1 byte representing a latin1 code point
     * @param b2 another byte representing a latin1 code point
     * @return true if the two bytes are considered equals ignoring case in latin1
     */
     static boolean equalsIgnoreCase(byte b1, byte b2) {
         if (b1 == b2) {
             return true;
         }
         int upper = b1 & 0xDF;
         if (upper < 'A') {
             return false;  // Low ASCII
         }
         return (upper <= 'Z' // In range A-Z
                 || (upper >= 0xC0 && upper <= 0XDE && upper != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
                 && upper == (b2 & 0xDF); // b2 has same uppercase
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From naoto at openjdk.org  Tue Feb 21 20:33:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 20:33:26 GMT
Subject: <i18n dev> RFR: 8302512: Update IANA Language Subtag Registry
 to Version 2023-02-14 [v2]
In-Reply-To: <M65a9-Cdfh9cNtFyivbLeL2F8982Aha4ecoLJ2XPsoI=.605031d4-80f4-4065-90bc-373f7e5927dd@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
 <M65a9-Cdfh9cNtFyivbLeL2F8982Aha4ecoLJ2XPsoI=.605031d4-80f4-4065-90bc-373f7e5927dd@github.com>
Message-ID: <YZqlfzSRU5ano5RTOCMUNy7gMpnXbS39VO_BShLPv38=.979de49b-a9d1-4496-9568-81fa967ea0ef@github.com>

On Tue, 21 Feb 2023 20:08:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Incorporate the latest IANA language subtag registry definition (2023-02-14).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright + correct date format

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From duke at openjdk.org  Tue Feb 21 20:36:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 20:36:32 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
Message-ID: <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>

On Tue, 21 Feb 2023 20:23:11 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 175:
>> 
>>> 173:          }
>>> 174:          // uppercase b1 using 'the oldest ASCII trick in the book'
>>> 175:          int U = b1 & 0xDF;
>> 
>> I'm sure some people reading this comment will wonder which book :-) It might be better to drop that bit and if possible, find a better name for "U" as normally variables start with a lower case.
>
> Hi Alan,
> 
> I thought I was clever by encoding the 'uppercaseness' in the variable name, but yeah I'll find a better name :)
> 
> There is some precedent for using the 'ASCII trick' comment in the JDK.  I found it in ZipFile.isMetaName, which is also where I first learned about this interesting relationship between ASCII (and also latin1) letters.
> 
> The comment was first added by Martin Buchholz back in 2016 as part of JDK-8157069, 'Assorted ZipFile improvements'. In 2020, Claes was updating this code and Lance has some input about clarifying the comment. Martin then [chimed in](https://mail.openjdk.org/pipermail/core-libs-dev/2020-May/066363.html) to defend his comment:
> 
>> I still like my ancient "ASCII trick" comment.
> 
> I think this 'trick', whatever we call it, is sufficiently intricate that it deserves to be called out somehow and that we should not just casually bitmask with these magic constants without any discussion at all. 
> 
> An earlier iteration of this PR included a small essay in the javadoc of this method describing the layout and relationship of letters in latin1 and how we can apply that knowledge of the layout to implement the method.
> 
> How would you feel about adding that description back to the Javadocs? This would then live close to the similarly implemented toUpperCase and toLowerCase methods currently under review in #12623. 
> 
> Here's the updated discussion included in the Javadoc:
> 
> 
>     /**
>      * Compares two latin1 code points, ignoring case considerations.
>      *
>      * Implementation note: In ISO/IEC 8859-1, the uppercase and lowercase
>      * letters are found in the following code point ranges:
>      *
>      * 0x41-0x5A: Uppercase ASCII letters: A-Z
>      * 0x61-0x7A: Lowercase ASCII letters: a-z
>      * 0xC0-0xD6: Uppercase latin1 letters: A-GRAVE - O with Diaeresis
>      * 0xD8-0xDE: Uppercase latin1 letters: O with slash - Thorn
>      * 0xE0-0xF6: Lowercase latin1 letters: a-grave - o with Diaeresis
>      * 0xF8-0xFE: Lowercase latin1 letters: o with slash - thorn
>      *
>      * While both ASCII letter ranges are contiguous, the latin1 ranges are not:
>      *
>      * The 'multiplication sign' 0xD7 splits the uppercase range in two.
>      * The 'division sign' 0xF7 splits the lowercase range in two.
>      *
>      * Lowercase letters are found 32 positions (0x20) after their corresponding uppercase letter.
>      * The 'division sign' and 'multiplication sign' have the same relative distance.
>      *
>      * Since 0x20 is a single bit, we can apply the 'oldest ASCII trick in the book' to
>      * lowercase any letter by setting the bit:
>      *
>      * ('C' | 0x20) == 'c'
>      *
>      * By removing the bit, we can perform the uppercase operation:
>      *
>      * ('c' & 0xDF) == 'C'
>      *
>      * Applying this knowledge of the latin1 layout, we can test for equality ignoring case by
>      * checking that the code points are either equal, or that one of the code points is a letter
>      * which uppercases is the same as the uppercase of the other code point.
>      *
>      * @param b1 byte representing a latin1 code point
>      * @param b2 another byte representing a latin1 code point
>      * @return true if the two bytes are considered equals ignoring case in latin1
>      */
>      static boolean equalsIgnoreCase(byte b1, byte b2) {
>          if (b1 == b2) {
>              return true;
>          }
>          int upper = b1 & 0xDF;
>          if (upper < 'A') {
>              return false;  // Low ASCII
>          }
>          return (upper <= 'Z' // In range A-Z
>                  || (upper >= 0xC0 && upper <= 0XDE && upper != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>                  && upper == (b2 & 0xDF); // b2 has same uppercase
>     }

Perhaps @Martin-Buchholz could chime in and also tell us which book he found his ASCII trick in :)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From tvaleev at openjdk.org  Tue Feb 21 20:39:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 21 Feb 2023 20:39:53 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v3]
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>

> 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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12633/files
  - new: https://git.openjdk.org/jdk/pull/12633/files/be13683b..e3fb1502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=01-02

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From tvaleev at openjdk.org  Tue Feb 21 20:39:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 21 Feb 2023 20:39:53 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v2]
In-Reply-To: <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
 <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>
Message-ID: <Niq36ljL-AlwQ8DKZmYxEw5D_g0YwcC9gKRn1fzsMyc=.e7fa2da2-f3eb-4313-aaab-4a8154cd20f2@github.com>

On Sun, 19 Feb 2023 08:54:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK
>
>> Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK
> 
> Yes, the jrt file system provider is compiled --release 8 to create lib/jrt-fs.jar. That's the plumbing needed to allow IDEs/tools running on JDK 8 access the contents of a target run-time image as a file system.

@AlanBateman thank you for review! Argh, I always forget about copyright year. Probably it's possible to update jcheck to make this check automated?

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From martin at openjdk.org  Tue Feb 21 20:50:29 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 20:50:29 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
Message-ID: <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>

On Tue, 21 Feb 2023 20:33:41 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Hi Alan,
>> 
>> I thought I was clever by encoding the 'uppercaseness' in the variable name, but yeah I'll find a better name :)
>> 
>> There is some precedent for using the 'ASCII trick' comment in the JDK.  I found it in ZipFile.isMetaName, which is also where I first learned about this interesting relationship between ASCII (and also latin1) letters.
>> 
>> The comment was first added by Martin Buchholz back in 2016 as part of JDK-8157069, 'Assorted ZipFile improvements'. In 2020, Claes was updating this code and Lance has some input about clarifying the comment. Martin then [chimed in](https://mail.openjdk.org/pipermail/core-libs-dev/2020-May/066363.html) to defend his comment:
>> 
>>> I still like my ancient "ASCII trick" comment.
>> 
>> I think this 'trick', whatever we call it, is sufficiently intricate that it deserves to be called out somehow and that we should not just casually bitmask with these magic constants without any discussion at all. 
>> 
>> An earlier iteration of this PR included a small essay in the javadoc of this method describing the layout and relationship of letters in latin1 and how we can apply that knowledge of the layout to implement the method.
>> 
>> How would you feel about adding that description back to the Javadocs? This would then live close to the similarly implemented toUpperCase and toLowerCase methods currently under review in #12623. 
>> 
>> Here's the updated discussion included in the Javadoc:
>> 
>> 
>>     /**
>>      * Compares two latin1 code points, ignoring case considerations.
>>      *
>>      * Implementation note: In ISO/IEC 8859-1, the uppercase and lowercase
>>      * letters are found in the following code point ranges:
>>      *
>>      * 0x41-0x5A: Uppercase ASCII letters: A-Z
>>      * 0x61-0x7A: Lowercase ASCII letters: a-z
>>      * 0xC0-0xD6: Uppercase latin1 letters: A-GRAVE - O with Diaeresis
>>      * 0xD8-0xDE: Uppercase latin1 letters: O with slash - Thorn
>>      * 0xE0-0xF6: Lowercase latin1 letters: a-grave - o with Diaeresis
>>      * 0xF8-0xFE: Lowercase latin1 letters: o with slash - thorn
>>      *
>>      * While both ASCII letter ranges are contiguous, the latin1 ranges are not:
>>      *
>>      * The 'multiplication sign' 0xD7 splits the uppercase range in two.
>>      * The 'division sign' 0xF7 splits the lowercase range in two.
>>      *
>>      * Lowercase letters are found 32 positions (0x20) after their corresponding uppercase letter.
>>      * The 'division sign' and 'multiplication sign' have the same relative distance.
>>      *
>>      * Since 0x20 is a single bit, we can apply the 'oldest ASCII trick in the book' to
>>      * lowercase any letter by setting the bit:
>>      *
>>      * ('C' | 0x20) == 'c'
>>      *
>>      * By removing the bit, we can perform the uppercase operation:
>>      *
>>      * ('c' & 0xDF) == 'C'
>>      *
>>      * Applying this knowledge of the latin1 layout, we can test for equality ignoring case by
>>      * checking that the code points are either equal, or that one of the code points is a letter
>>      * which uppercases is the same as the uppercase of the other code point.
>>      *
>>      * @param b1 byte representing a latin1 code point
>>      * @param b2 another byte representing a latin1 code point
>>      * @return true if the two bytes are considered equals ignoring case in latin1
>>      */
>>      static boolean equalsIgnoreCase(byte b1, byte b2) {
>>          if (b1 == b2) {
>>              return true;
>>          }
>>          int upper = b1 & 0xDF;
>>          if (upper < 'A') {
>>              return false;  // Low ASCII
>>          }
>>          return (upper <= 'Z' // In range A-Z
>>                  || (upper >= 0xC0 && upper <= 0XDE && upper != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>>                  && upper == (b2 & 0xDF); // b2 has same uppercase
>>     }
>
> Perhaps @Martin-Buchholz could chime in and also tell us which book he found his ASCII trick in :)

"oldest trick in the book" is a phrase that does not necessarily imply existence of an actual book!

Let this evoke an image of a **personal** book of tricks that programmers in the 1960s might have recorded such techniques in.  And the tricks were passed down across generations of programmers!

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 20:57:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 20:57:43 GMT
Subject: <i18n dev> Integrated: 8302877: Speed up latin1 case conversions
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <j2UqaMozv8HwYxJwclrcNj0r8ubGzjNB1NYjnWZOF04=.19b23953-321d-4418-93ae-f15eed25ed1f@github.com>

On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

This pull request has now been integrated.

Changeset: ef1f7bd3
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef1f7bd3b80f8777c15ab22b1dff7dfe4f084734
Stats:     166 lines in 5 files changed: 143 ins; 0 del; 23 mod

8302877: Speed up latin1 case conversions

Reviewed-by: naoto, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From dholmes at openjdk.org  Tue Feb 21 21:18:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 21:18:25 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <nLsLehUDD-Cj_q4XSWSJuWA4_h4J5IbbdrIVZ-eJNQs=.fa2e1c5a-8d51-4e69-879e-67e4cde22163@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

The testcase change is failing to compile:

open/test/micro/org/openjdk/bench/java/lang/Characters.java:115: error: case, default, or '}' expected

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:25:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:25:42 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <nLsLehUDD-Cj_q4XSWSJuWA4_h4J5IbbdrIVZ-eJNQs=.fa2e1c5a-8d51-4e69-879e-67e4cde22163@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
 <nLsLehUDD-Cj_q4XSWSJuWA4_h4J5IbbdrIVZ-eJNQs=.fa2e1c5a-8d51-4e69-879e-67e4cde22163@github.com>
Message-ID: <RxtkFj8maWzmcFTfQIjx7UlFm3FR-u7F_pk3rdCWgwM=.7de7d3d9-eebd-4137-9964-e89155556cd3@github.com>

On Tue, 21 Feb 2023 21:15:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The testcase change is failing to compile:
> 
> ```
> open/test/micro/org/openjdk/bench/java/lang/Characters.java:115: error: case, default, or '}' expected
> ```

Darn, this was rather embarrassing!

Since this was just integrated, I guess I'll need to open a new PR for the fix?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From naoto at openjdk.org  Tue Feb 21 21:31:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 21:31:48 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <Gm25gOuSTwhdaa6-1_kmZPcaipBwT-sxZZuJKXiODLk=.cc673786-e735-443c-a71a-488742b1b42a@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

Yes please.

https://bugs.openjdk.org/browse/JDK-8303033

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:31:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:31:49 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <bHxHuUqbwQLwSc2A4QEtv6YdBw_MnEPPTAzIcfq0uy0=.75238e82-2df1-42e7-bf5f-ae0c04b69757@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

I created https://github.com/openjdk/jdk/pull/12701 for this.

Could someone please file a JBS?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:36:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:36:43 GMT
Subject: <i18n dev> RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <8RDZdTFOOIyMzejhh_oAcGIJLf88g-nmr_4c18TRGY0=.45504582-6caf-47c4-ace5-d02db0cbab37@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> 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 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

Thanks, #12701 is ready for review.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:53:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:53:10 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v8]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <j5TbvwLVJlvUENV1DpAiM7yVwP0WZVwIAAZjVR0YCew=.9b029f6c-6a25-4b54-a07d-b67a81f948e6@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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 13 additional commits since the last revision:

 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Remove whitespace following '('
 - Revert "Spell fix for 'exhaustive' in comments in sun/text/resources"
   
   This reverts commit 5e9927a4b35e157fd3fa72fd2663c8bfbecf32bb.
 - Spell fix for 'exhaustive' in comments in sun/text/resources
 - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
 - Add @bug tag to EqualsIgnoreCase test for JDK-8302877
 - Add clarifying comments and use more descriptive variable names in the latin1 verification EqualsIgnoreCase test
 - Align whitespace to make example strings easier to read
 - Merge branch 'master' into regionmatches-latin1-speedup
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ea62160f...718fcead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/d7b1c164..718fcead

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=06-07

  Stats: 4282 lines in 198 files changed: 2630 ins; 1129 del; 523 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 21:59:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:59:33 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
Message-ID: <wukr9CAXv6eg4V1zyaY_u4MQzosphMXOT69KQ5qNpXE=.05e4ce9a-dd12-4e4d-bf78-f188a0386bf9@github.com>

On Tue, 21 Feb 2023 14:22:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove whitespace following '('
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 163:
> 
>> 161:         return mapChar;
>> 162:     }
>> 163:     /**
> 
> I assume you should insert a blank line between the two methods.

This has been fixed now.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 22:37:57 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 22:37:57 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v9]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <_990kr_t2d7W83RQP9S871Hs-supvu4a8A_LAVmiAyw=.2ed8b149-8628-43a1-8c20-92caca5f2983@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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 15 additional commits since the last revision:

 - Rename unconventionally named local variable 'U' to 'upper'
 - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Remove whitespace following '('
 - Revert "Spell fix for 'exhaustive' in comments in sun/text/resources"
   
   This reverts commit 5e9927a4b35e157fd3fa72fd2663c8bfbecf32bb.
 - Spell fix for 'exhaustive' in comments in sun/text/resources
 - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
 - Add @bug tag to EqualsIgnoreCase test for JDK-8302877
 - Add clarifying comments and use more descriptive variable names in the latin1 verification EqualsIgnoreCase test
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7025e4c5...6588ab0f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/718fcead..6588ab0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=07-08

  Stats: 20 lines in 6 files changed: 0 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Tue Feb 21 23:22:25 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 23:22:25 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
Message-ID: <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>

On Tue, 21 Feb 2023 20:48:04 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Perhaps @Martin-Buchholz could chime in and also tell us which book he found his ASCII trick in :)
>
> "oldest trick in the book" is a phrase that does not necessarily imply existence of an actual book!
> 
> Let this evoke an image of a **personal** book of tricks that programmers in the 1960s might have recorded such techniques in.  And the tricks were passed down across generations of programmers!

More to the point, ASCII was obviously **designed** to allow you to uppercase a lower case letter with a single instruction, so "the book" might have been a draft standard before they scrubbed out the interesting history!

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 23:31:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 23:31:27 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
Message-ID: <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>

On Tue, 21 Feb 2023 23:20:03 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> "oldest trick in the book" is a phrase that does not necessarily imply existence of an actual book!
>> 
>> Let this evoke an image of a **personal** book of tricks that programmers in the 1960s might have recorded such techniques in.  And the tricks were passed down across generations of programmers!
>
> More to the point, ASCII was obviously **designed** to allow you to uppercase a lower case letter with a single instruction, so "the book" might have been a draft standard before they scrubbed out the interesting history!

Thanks Martin, I will from now on envision a stack of dusty punch cards with carefully scribbled notes on the back, barely held together with a dry and cracked rubber band.

More to the point: Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? My goal is that future maintainers should not get scared by the code and help them understand why it became what it is.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From dholmes at openjdk.org  Wed Feb 22 00:09:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Feb 2023 00:09:29 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
Message-ID: <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>

On Tue, 21 Feb 2023 23:28:52 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> More to the point, ASCII was obviously **designed** to allow you to uppercase a lower case letter with a single instruction, so "the book" might have been a draft standard before they scrubbed out the interesting history!
>
> Thanks Martin, I will from now on envision a stack of dusty punch cards with carefully scribbled notes on the back, barely held together with a dry and cracked rubber band.
> 
> More to the point: Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? My goal is that future maintainers should not get scared by the code and help them understand why it became what it is.

There are still some books on this :) but from wikipedia:
> during May 1963 the CCITT Working Party on the New Telegraph Alphabet proposed to assign lowercase characters to sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7,[[15]](https://en.wikipedia.org/wiki/ASCII#cite_note-CCITT_1963-16) and [International Organization for Standardization](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) TC 97 SC 2 voted during October to incorporate the change into its draft standard.[[16]](https://en.wikipedia.org/wiki/ASCII#cite_note-ISO_1963-17) The X3.2.4 task group voted its approval for the change to ASCII at its May 1963 meeting.[[17]](https://en.wikipedia.org/wiki/ASCII#cite_note-18) **Locating the lowercase letters in sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7 caused the characters to differ in bit pattern f
 rom the upper case by a single bit, which simplified [case-insensitive](https://en.wikipedia.org/wiki/Case-insensitive) character matching and the construction of keyboards and printers.**

Hence the simplicity of the shift key :)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Wed Feb 22 00:48:33 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 00:48:33 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
Message-ID: <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>

On Wed, 22 Feb 2023 00:06:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks Martin, I will from now on envision a stack of dusty punch cards with carefully scribbled notes on the back, barely held together with a dry and cracked rubber band.
>> 
>> More to the point: Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? My goal is that future maintainers should not get scared by the code and help them understand why it became what it is.
>
> There are still some books on this :) but from wikipedia:
>> during May 1963 the CCITT Working Party on the New Telegraph Alphabet proposed to assign lowercase characters to sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7,[[15]](https://en.wikipedia.org/wiki/ASCII#cite_note-CCITT_1963-16) and [International Organization for Standardization](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) TC 97 SC 2 voted during October to incorporate the change into its draft standard.[[16]](https://en.wikipedia.org/wiki/ASCII#cite_note-ISO_1963-17) The X3.2.4 task group voted its approval for the change to ASCII at its May 1963 meeting.[[17]](https://en.wikipedia.org/wiki/ASCII#cite_note-18) **Locating the lowercase letters in sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7 caused the characters to differ in bit pattern 
 from the upper case by a single bit, which simplified [case-insensitive](https://en.wikipedia.org/wiki/Case-insensitive) character matching and the construction of keyboards and printers.**
> 
> Hence the simplicity of the shift key :)

More history: IIRC I originally used 'ASCII trick' when I was truly only cared about ASCII, not Latin1 (e.g. ZipFile.isMetaName) and it's a slight misnomer to use "ASCII" here.  But Latin1 followed the precedent of ASCII.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Wed Feb 22 00:53:35 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 00:53:35 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
Message-ID: <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7HXlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>

On Wed, 22 Feb 2023 00:45:52 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> There are still some books on this :) but from wikipedia:
>>> during May 1963 the CCITT Working Party on the New Telegraph Alphabet proposed to assign lowercase characters to sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7,[[15]](https://en.wikipedia.org/wiki/ASCII#cite_note-CCITT_1963-16) and [International Organization for Standardization](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) TC 97 SC 2 voted during October to incorporate the change into its draft standard.[[16]](https://en.wikipedia.org/wiki/ASCII#cite_note-ISO_1963-17) The X3.2.4 task group voted its approval for the change to ASCII at its May 1963 meeting.[[17]](https://en.wikipedia.org/wiki/ASCII#cite_note-18) **Locating the lowercase letters in sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7 caused the characters to differ in bit pattern
  from the upper case by a single bit, which simplified [case-insensitive](https://en.wikipedia.org/wiki/Case-insensitive) character matching and the construction of keyboards and printers.**
>> 
>> Hence the simplicity of the shift key :)
>
> More history: IIRC I originally used 'ASCII trick' when I was truly only cared about ASCII, not Latin1 (e.g. ZipFile.isMetaName) and it's a slight misnomer to use "ASCII" here.  But Latin1 followed the precedent of ASCII.

> Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? 

This code is not that tricky!  And the proposed level of documentation is excessive!  A couple of lines of explanation and perhaps a link to an external document would be good.

It often happens to me that I will write such exhaustive notes for myself when learning a new technology.  A year later I pare it all back because much of it is "obvious in retrospect".

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 07:11:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 07:11:16 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v10]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
 - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/6588ab0f..44d91544

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=08-09

  Stats: 11 lines in 1 file changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 07:15:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 07:15:44 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7HXlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
 <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7H
 Xlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
Message-ID: <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>

On Wed, 22 Feb 2023 00:50:39 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> More history: IIRC I originally used 'ASCII trick' when I was truly only cared about ASCII, not Latin1 (e.g. ZipFile.isMetaName) and it's a slight misnomer to use "ASCII" here.  But Latin1 followed the precedent of ASCII.
>
>> Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? 
> 
> This code is not that tricky!  And the proposed level of documentation is excessive!  A couple of lines of explanation and perhaps a link to an external document would be good.
> 
> It often happens to me that I will write such exhaustive notes for myself when learning a new technology.  A year later I pare it all back because much of it is "obvious in retrospect".

Thanks Martin, David, Alan.  This was instructive (and fun!)

I suggest we condense the comment to something like this:


// Uppercase b1 by removing a single bit
int upper = b1 & 0xDF;
if (upper < 'A') {
    return false;  // Low ASCII
}
...


The similar methods `toLowerCase` `toUpperCase` just above have been updated to follow the same style. (I also updated local variable names there to align better with equalsIgnoreCase)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From tvaleev at openjdk.org  Wed Feb 22 09:55:00 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 22 Feb 2023 09:55:00 GMT
Subject: <i18n dev> Integrated: 8302815 Use new Math.clamp method in core
 libraries
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <uneJh9xm0xpMTSGWibl3hpkaSaC5iYGsmwF7VaAdspc=.0b5c502d-06fc-4ea7-b3e9-80ae9d02d551@github.com>

On Sat, 18 Feb 2023 10:50:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> 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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

This pull request has now been integrated.

Changeset: 3f3a1f53
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f3a1f534b7f2f5be6d7ded9d9832fa9394e763c
Stats:     45 lines in 11 files changed: 0 ins; 8 del; 37 mod

8302815: Use new Math.clamp method in core libraries

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From alanb at openjdk.org  Wed Feb 22 10:00:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 10:00:31 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <78oXv8oehtNFwbwcPyczGNkWZcLFjxWH4pUDin1KTTI=.ca90d92f-04d2-47cc-8da9-e956f315046f@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 211:

> 209: 
> 210:     // Lazily initialized system property value
> 211:     private static String GB18030_2000;

I assume this should be a stable field.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Wed Feb 22 10:48:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 22 Feb 2023 10:48:55 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:

> 215:             if (VM.initLevel() < 1) {
> 216:                 // Cannot get the system property yet. Assumes non-2000
> 217:                 GB18030_2000 = "";

curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Wed Feb 22 11:38:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 11:38:14 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022
In-Reply-To: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
Message-ID: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>

On Wed, 22 Feb 2023 10:46:10 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> curious - what scenario triggers this call at initLevel < 1 ?

It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From redestad at openjdk.org  Wed Feb 22 11:38:16 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 Feb 2023 11:38:16 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v10]
In-Reply-To: <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
Message-ID: <o8nPvFS7H1eCXYDFaU9hXQH7UXEUNbLyL4iUXF9auNA=.5da1cf45-61f8-4d0a-9867-af6e352cb918@github.com>

On Wed, 22 Feb 2023 07:11:16 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Wed Feb 22 15:22:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 15:22:04 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <TEAzveqaYCtriT9l0ikO71z2k7_mBhd5AD6s2t-YPyw=.253b065a-90f1-4f84-a7de-fdc71326d91d@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Overall I think it looks very good, just StandardCharsets.isGB18030_2000 needs attention. Having GB18030 be in java.base in all builds, rather than everywhere except macOS, is okay and makes things a lot simpler.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From prappo at openjdk.org  Wed Feb 22 15:22:20 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Feb 2023 15:22:20 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v3]
In-Reply-To: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
Message-ID: <He-VgS2FvvHi-RPJtoeJpwVI-U6A_xkjLEGNGg0HRsI=.19cf5b10-85b5-49f9-b737-91b8b63b2fc5@github.com>

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> 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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I only saw this PR after it has been integrated. A code location that immediately came to mind but was missing in the change is this java/util/concurrent/SubmissionPublisher.java:1273:

       public final void request(long n) {
            if (n > 0L) {
                for (;;) {
                    long p = demand, d = p + n;  // saturate
                    if (casDemand(p, d < p ? Long.MAX_VALUE : d))
                        break;
                }
                startOnSignal(RUN | ACTIVE | REQS);
            }
            else
                onError(new IllegalArgumentException(
                            "non-positive subscription request"));
        }

Seems like a poster child for the new Math.clamp functionality.

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From prappo at openjdk.org  Wed Feb 22 15:51:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Feb 2023 15:51:32 GMT
Subject: <i18n dev> RFR: 8302815 Use new Math.clamp method in core
 libraries [v3]
In-Reply-To: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
Message-ID: <l_a3OOnnWIBEV5S43T_ZYSxD_uSEAt36wCBc0VG_v4M=.dbe3fc8b-95ce-431b-9bfd-d01ca815aa29@github.com>

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> 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 replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

On second thought, maybe not; Math.clamp might actually look more clumsy here. Scratch my previous comment.

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From martin at openjdk.org  Wed Feb 22 16:13:19 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 16:13:19 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
 <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7H
 Xlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
 <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>
Message-ID: <kQUjwQx49nXUAbkb9DPMqYt_tXXeY_Mj-xg11mq9MAo=.c213bbd8-ac1f-4dbc-92c2-07d74971d90d@github.com>

On Wed, 22 Feb 2023 07:12:35 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>>> Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? 
>> 
>> This code is not that tricky!  And the proposed level of documentation is excessive!  A couple of lines of explanation and perhaps a link to an external document would be good.
>> 
>> It often happens to me that I will write such exhaustive notes for myself when learning a new technology.  A year later I pare it all back because much of it is "obvious in retrospect".
>
> Thanks Martin, David, Alan.  This was instructive (and fun!)
> 
> I suggest we condense the comment to something like this:
> 
> 
> // Uppercase b1 by removing a single bit
> int upper = b1 & 0xDF;
> if (upper < 'A') {
>     return false;  // Low ASCII
> }
> ...
> 
> 
> The similar methods `toLowerCase` `toUpperCase` just above have been updated to follow the same style. (I also updated local variable names there to align better with equalsIgnoreCase)

// ASCII and Latin-1 were designed to optimize case-twiddling operations

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:33:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:33:37 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v11]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <sd7RuPZUgt7KggOg_OT5tUxW0Slo0CMfjOBQRfI844c=.1d611efc-7d48-4b61-a879-462a82f994ea@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use improved case-twiddling comment as suggested by Martin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/44d91544..ea2f9fa3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Wed Feb 22 16:33:39 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 16:33:39 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v10]
In-Reply-To: <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
Message-ID: <ZwyELe_UasYsl4s-6aXe-p1_Wh7DotuAjf1gkoika8s=.d0834fea-1d55-4b77-a33f-09894208909e@github.com>

On Wed, 22 Feb 2023 07:11:16 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'

Marked as reviewed by martin (Reviewer).

test/jdk/java/lang/String/CompactString/EqualsIgnoreCase.java line 89:

> 87:         for (int ab = 0; ab < 256; ab++) {
> 88:             for (int bb = 0; bb < 256; bb++) {
> 89:                 char a = (char) ab, b = (char) bb;

char is an unsigned numeric type, so cleaner is

for (char a = 0; a < 256; a++) 
for (char b = 0; b < 256; b++)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:33:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:33:43 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v7]
In-Reply-To: <kQUjwQx49nXUAbkb9DPMqYt_tXXeY_Mj-xg11mq9MAo=.c213bbd8-ac1f-4dbc-92c2-07d74971d90d@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
 <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7H
 Xlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
 <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>
 <kQUjwQx49nXUAbkb9DPMqYt_tXXeY_Mj-xg11mq9MAo=.c213bbd8-ac1f-4dbc-92c2-07d74971d90d@github.com>
Message-ID: <MBMpAbrifq2o4SdgfzX49odU9VxE25nfDShPIUthFUA=.ba07b8da-49d2-4d61-8ddb-f33f5592456e@github.com>

On Wed, 22 Feb 2023 16:10:42 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Thanks Martin, David, Alan.  This was instructive (and fun!)
>> 
>> I suggest we condense the comment to something like this:
>> 
>> 
>> // Uppercase b1 by removing a single bit
>> int upper = b1 & 0xDF;
>> if (upper < 'A') {
>>     return false;  // Low ASCII
>> }
>> ...
>> 
>> 
>> The similar methods `toLowerCase` `toUpperCase` just above have been updated to follow the same style. (I also updated local variable names there to align better with equalsIgnoreCase)
>
> // ASCII and Latin-1 were designed to optimize case-twiddling operations

Thanks! This expresses the higher-level benefit succinctly, without getting into the details. I like it!

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:37:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:37:45 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v12]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Make the loop variables chars to avoid casting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/ea2f9fa3..cc185293

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:37:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:37:48 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v10]
In-Reply-To: <ZwyELe_UasYsl4s-6aXe-p1_Wh7DotuAjf1gkoika8s=.d0834fea-1d55-4b77-a33f-09894208909e@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
 <ZwyELe_UasYsl4s-6aXe-p1_Wh7DotuAjf1gkoika8s=.d0834fea-1d55-4b77-a33f-09894208909e@github.com>
Message-ID: <DKDvJbU1Z8MMQhFNBDQaREjyu-r93limVBhp6K9gkLA=.e12a473c-8ddb-4bb8-82cd-b5aa75926b02@github.com>

On Wed, 22 Feb 2023 16:25:41 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>
> test/jdk/java/lang/String/CompactString/EqualsIgnoreCase.java line 89:
> 
>> 87:         for (int ab = 0; ab < 256; ab++) {
>> 88:             for (int bb = 0; bb < 256; bb++) {
>> 89:                 char a = (char) ab, b = (char) bb;
> 
> char is an unsigned numeric type, so cleaner is
> 
> for (char a = 0; a < 256; a++) 
> for (char b = 0; b < 256; b++)

Thanks, fixed. Might have been copied over from processing of code points in the higher planes. Not needed here.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From naoto at openjdk.org  Wed Feb 22 18:22:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:33 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <zjw9cgUgI3rGDV9gW7xcpCuSpDeBi10TK7AZoSjP970=.81f3937a-b471-4bf7-8bc5-ebaf0c9f0ae7@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

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 16 additional commits since the last revision:

 - Add @Stable annotation
 - Merge branch 'master' into JDK-8301119-GB18030-2022
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - ... and 6 more: https://git.openjdk.org/jdk/compare/0981ec17...b5379b69

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/0f3c25ce..b5379b69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00-01

  Stats: 8209 lines in 333 files changed: 4912 ins; 1488 del; 1809 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Wed Feb 22 18:22:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:41 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
Message-ID: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>

On Wed, 22 Feb 2023 11:34:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:
>> 
>>> 215:             if (VM.initLevel() < 1) {
>>> 216:                 // Cannot get the system property yet. Assumes non-2000
>>> 217:                 GB18030_2000 = "";
>> 
>> curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)
>
>> curious - what scenario triggers this call at initLevel < 1 ?
> 
> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

`Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From duke at openjdk.org  Wed Feb 22 18:47:58 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 18:47:58 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v12]
In-Reply-To: <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>
Message-ID: <J7Di2ZhG37ghp5kb0_MU7O5FeB41l8k3rXT20sPFQRA=.cc7c2a2b-9427-4553-807f-84e20ab8e304@github.com>

On Wed, 22 Feb 2023 16:37:45 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the loop variables chars to avoid casting

Thanks for reviews Claes and Martin! I'll let this linger a bit before integrating in case Alan has comments after the latest updates.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 19:35:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 19:35:18 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v13]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <LtIEN57XcTW6xwwqEK2vZSwGFgywtNa9XlibXdMgOfQ=.c6c2f0c2-cb91-4619-ad72-5b6b7dc2c951@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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 20 additional commits since the last revision:

 - Merge branch 'master' into regionmatches-latin1-speedup
 - Make the loop variables chars to avoid casting
 - Use improved case-twiddling comment as suggested by Martin
 - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
 - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
 - Rename unconventionally named local variable 'U' to 'upper'
 - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Remove whitespace following '('
 - ... and 10 more: https://git.openjdk.org/jdk/compare/ea132c56...fe4efe9f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/cc185293..fe4efe9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=11-12

  Stats: 1397 lines in 120 files changed: 873 ins; 291 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 20:01:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 20:01:52 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v14]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>

> 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`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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 21 additional commits since the last revision:

 - Merge branch 'master' into regionmatches-latin1-speedup
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Make the loop variables chars to avoid casting
 - Use improved case-twiddling comment as suggested by Martin
 - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
 - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
 - Rename unconventionally named local variable 'U' to 'upper'
 - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - ... and 11 more: https://git.openjdk.org/jdk/compare/e7379286...597b346a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/fe4efe9f..597b346a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=12-13

  Stats: 9 lines in 5 files changed: 1 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From naoto at openjdk.org  Wed Feb 22 20:46:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 20:46:50 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>

On Tue, 21 Feb 2023 13:44:52 GMT, Madjosz <duke at openjdk.org> wrote:

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Thanks for fixing this. Some comments follow.

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 43:

> 41: /**
> 42:  * @summary Tests for ZoneRulesProvider class.
> 43:  * @bug 8299571

Can be collapsed into one line

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 119:

> 117:                 return null;
> 118:             }
> 119:         }

Needs a semi-colon, otherwise would not compile.
Anyway, this inner class can be combined with the one in the test above, and made into a separate class.

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 123:

> 121:         ZoneRulesProvider.registerProvider(provider);
> 122:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + zone);
> 123:         assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should be obtainable");

If the `zone` does not exist, it will not return `null` but throw an exception. Assertion needs to be modified correctly.

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 136:

> 134:         // instantiation check
> 135:         try {
> 136:             assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should still be obtainable");

Same here.

-------------

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Thu Feb 23 07:24:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Feb 2023 07:24:09 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v14]
In-Reply-To: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
Message-ID: <XED8lqe6CSvbat23n7oRTa-Ae1z4sTH_2WFffXTaVls=.ab7ddc41-314e-479a-a0e3-b99698fcc58d@github.com>

On Wed, 22 Feb 2023 20:01:52 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos 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 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Make the loop variables chars to avoid casting
>  - Use improved case-twiddling comment as suggested by Martin
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>  - Rename unconventionally named local variable 'U' to 'upper'
>  - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
>  - Add whitespace between methods
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/31689be3...597b346a

I found this in Appendix A of the 1973 `Draft Proposed Revision of ASCII`. Seems compatibility with existing 6-bit devices might have been the primary concern:


A 6.4 It is expected that devices having the capability of
printing only 64 graphic symbols will continue to be important.
It may be desirable to arrange these devices to print one symbol
for the bit pattern of both upper and lower case of a given
alphabetic letter. To facilitate this, there should be a single-
bit difference between the upper and lowercase representations
of any given letter. Combined with the requirement that a given
case of the alphabet be contiguous, this dictated the assignment
of the alphabet, as shown in columns 4 through 7.

<img width="932" alt="ascii" src="https://user-images.githubusercontent.com/300291/220842000-3efa64fe-9154-4069-9e81-e202d5731f6f.png">

https://ia800606.us.archive.org/17/items/enf-ascii-1972-1975/Image070917152640_text.pdf

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Thu Feb 23 07:44:07 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Feb 2023 07:44:07 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v14]
In-Reply-To: <XED8lqe6CSvbat23n7oRTa-Ae1z4sTH_2WFffXTaVls=.ab7ddc41-314e-479a-a0e3-b99698fcc58d@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
 <XED8lqe6CSvbat23n7oRTa-Ae1z4sTH_2WFffXTaVls=.ab7ddc41-314e-479a-a0e3-b99698fcc58d@github.com>
Message-ID: <8heTHvSrS9Q2XvuOP1APjeSLy82m8fF9LHSFhCj7YTk=.b6beea59-eabc-4c48-af51-937e1a94d8e0@github.com>

On Thu, 23 Feb 2023 07:21:08 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Seems compatibility with existing 6-bit devices might have been the primary concern:

This also explains the placement of brackets, braces, bars, tilde etc. They would look visually similar on 6-bit devices:

<img width="915" alt="image" src="https://user-images.githubusercontent.com/300291/220845393-de12301a-73e2-46fe-a6ce-ce101d0a2b3b.png">

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From redestad at openjdk.org  Thu Feb 23 08:35:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:35:04 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
Message-ID: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>

On Wed, 22 Feb 2023 17:52:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> curious - what scenario triggers this call at initLevel < 1 ?
>> 
>> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.
>
> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

`@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.

I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jlu at openjdk.org  Thu Feb 23 08:48:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Feb 2023 08:48:45 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales
Message-ID: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>

This PR proposes introducing a new method to Locale which returns Stream<Locale>

It involves adding an additional method to _LocaleServiceProviderPool_ that returns Stream, which _Locale_ can call.

`LocaleServiceProviderPool.streamAllAvaliableLocales()` does not need a defensive copy of `AllAvailableLocales.allAvailableLocales` unlike `LocaleServiceProviderPool.getAllAvaliableLocales()` as the array is hidden by the Stream.

-------------

Commit messages:
 - Adjust test for new method name
 - Update specification for method
 - Update impl to use @since, {@return..., @implNote
 - Further revert of name change
 - Revert changed var name
 - There is no need to retain the set, Stream the array directly
 - Adjust err msg
 - Run w/ data provider
 - Tweak var names
 - Merge branch 'master' into 8282319-Locale-Stream
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7eff5787...6df5c168

Changes: https://git.openjdk.org/jdk/pull/12269/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282319
  Stats: 115 lines in 3 files changed: 112 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From stsypanov at openjdk.org  Thu Feb 23 08:48:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Feb 2023 08:48:47 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <7WL_dTHmieqFW3T-zx85ElASEk8SkC9W74d4RDzUjOA=.0f03ae8c-e204-4722-9d9b-727104c0ad99@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR proposes introducing a new method to Locale which returns Stream<Locale>
> 
> It involves adding an additional method to _LocaleServiceProviderPool_ that returns Stream, which _Locale_ can call.
> 
> `LocaleServiceProviderPool.streamAllAvaliableLocales()` does not need a defensive copy of `AllAvailableLocales.allAvailableLocales` unlike `LocaleServiceProviderPool.getAllAvaliableLocales()` as the array is hidden by the Stream.

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 160:

> 158:      */
> 159:     public static Stream<Locale> streamAvailableLocales() {
> 160:         return AllAvailableLocales.AvailableLocalesSet.stream();

I think we could use `Stream.of(AllAvailableLocales.availableLocalesArray)` here and drop set field.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Thu Feb 23 08:48:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Feb 2023 08:48:48 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales
In-Reply-To: <7WL_dTHmieqFW3T-zx85ElASEk8SkC9W74d4RDzUjOA=.0f03ae8c-e204-4722-9d9b-727104c0ad99@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <7WL_dTHmieqFW3T-zx85ElASEk8SkC9W74d4RDzUjOA=.0f03ae8c-e204-4722-9d9b-727104c0ad99@github.com>
Message-ID: <xX7L_i5MrVzYX2z5HYWHurPaYiS6mwHjhVZho8IG8So=.c996fca2-a6f1-4f53-9056-771f0a434565@github.com>

On Mon, 30 Jan 2023 07:11:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> This PR proposes introducing a new method to Locale which returns Stream<Locale>
>> 
>> It involves adding an additional method to _LocaleServiceProviderPool_ that returns Stream, which _Locale_ can call.
>> 
>> `LocaleServiceProviderPool.streamAllAvaliableLocales()` does not need a defensive copy of `AllAvailableLocales.allAvailableLocales` unlike `LocaleServiceProviderPool.getAllAvaliableLocales()` as the array is hidden by the Stream.
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 160:
> 
>> 158:      */
>> 159:     public static Stream<Locale> streamAvailableLocales() {
>> 160:         return AllAvailableLocales.AvailableLocalesSet.stream();
> 
> I think we could use `Stream.of(AllAvailableLocales.availableLocalesArray)` here and drop set field.

Yes you're right, I had misinterpreted the original bug description. Set is not required, and in fact the array should be streamed directly as you said.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From redestad at openjdk.org  Thu Feb 23 08:58:02 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:58:02 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
Message-ID: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>

On Thu, 23 Feb 2023 08:32:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.
>
> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
> 
> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:


    isGB18030_2000() { return GB18030Properties.GB18030_2000; }

    private static class GB18030Properties {
        private static final GB18030_2000 = init();
        private static boolean init() {
            if (VM.initLevel() < 1) {
                // Cannot get the system property yet. Assumes non-2000
                return false;
            }
            return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
        }
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Thu Feb 23 09:07:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 09:07:10 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
Message-ID: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>

On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
>> 
>> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.
>
> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
> 
> 
>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
> 
>     private static class GB18030Properties {
>         private static final GB18030_2000 = init();
>         private static boolean init() {
>             if (VM.initLevel() < 1) {
>                 // Cannot get the system property yet. Assumes non-2000
>                 return false;
>             }
>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>         }
>     }

Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Thu Feb 23 09:51:06 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 23 Feb 2023 09:51:06 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
Message-ID: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>

On Thu, 23 Feb 2023 09:03:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
>> 
>> 
>>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
>> 
>>     private static class GB18030Properties {
>>         private static final GB18030_2000 = init();
>>         private static boolean init() {
>>             if (VM.initLevel() < 1) {
>>                 // Cannot get the system property yet. Assumes non-2000
>>                 return false;
>>             }
>>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>>         }
>>     }
>
> Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Thu Feb 23 10:10:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 10:10:08 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
Message-ID: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>

On Thu, 23 Feb 2023 09:48:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From stsypanov at openjdk.org  Thu Feb 23 15:37:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Feb 2023 15:37:05 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <qWSTzMpfYXXnZpaze3oVaIlK3GBrC40TmNag1vjrjAA=.7306c104-160a-4d1a-b8fc-756f039c7426@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Marked as reviewed by stsypanov (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Thu Feb 23 19:09:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Feb 2023 19:09:16 GMT
Subject: <i18n dev> Integrated: 8302512: Update IANA Language Subtag
 Registry to Version 2023-02-14
In-Reply-To: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
Message-ID: <1hhzooWrC54oyOD__Fdb5yxWgLAPZOJg-cs2DQGga6c=.307d42ba-f4aa-45d5-a046-85cc8c142ec7@github.com>

On Tue, 21 Feb 2023 19:26:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Incorporate the latest IANA language subtag registry definition (2023-02-14).

This pull request has now been integrated.

Changeset: f612dcfe
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f612dcfebea7ffd4390f833646ad45d6f0ebd04f
Stats:     10 lines in 2 files changed: 6 ins; 0 del; 4 mod

8302512: Update IANA Language Subtag Registry to Version 2023-02-14

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From naoto at openjdk.org  Thu Feb 23 19:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:34:44 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Moved the 2000 flag into GB18030

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/b5379b69..4d4015a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=01-02

  Stats: 28 lines in 3 files changed: 6 ins; 18 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Thu Feb 23 19:36:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:36:10 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
 <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
Message-ID: <B4IvJCeiXPoSRP0Zr5eaSdK6GzcoWoZ6jjytYs80yxw=.546521a6-49b5-4aaf-8b3a-09ddc25aa5d3@github.com>

On Thu, 23 Feb 2023 10:07:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
>
>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
> 
> The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

> what this code is really reaching for is `static final` field semantics.

Exactly. Introducing the holder pattern in `StandardCharset` would solve the issue, but instead I moved the flag init into `GB18030` so that we can literally make it `static final`.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Thu Feb 23 20:02:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 20:02:14 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <eIxZtTHU52wM5tLjvZ_shX59yv_w7s-ZHQydk0wnuOI=.b494d36b-48e9-4347-8454-968f7c163a36@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Looks good. Some minor comments follow.

src/java.base/share/classes/java/util/Locale.java line 1223:

> 1221:      * {@code Locale} instance equal to {@link Locale#ROOT Locale.ROOT} and
> 1222:      * a {@code Locale} instance equal to {@link Locale#US Locale.US}.
> 1223:      * @implNote Unlike {@code getAvailableLocales()}, this method does

I'd insert a blank line between the method description paragraphs and the following javadoc tags.

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:

> 153:      * that are provided by each provider, including the JRE.
> 154:      *
> 155:      * @return a stream of the available locales for all provider classes

Could use {@return } as well.

test/jdk/java/util/Locale/StreamAvailableLocales.java line 26:

> 24:  * @test
> 25:  * @summary Test the implementation
> 26:  * of Locale.streamAvailableLocales()

`availableLocales()`? There are other locations using the name too.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlaskey at openjdk.org  Thu Feb 23 20:08:21 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 20:08:21 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v41]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <8acQaVjcsJLZjZv02chxRMODQ1wJnJ6zvb5IkaIGH2w=.94b6a788-b129-4623-bd4e-ecaaeb4bce37@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits:

 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - ... and 46 more: https://git.openjdk.org/jdk/compare/6b24b4a7...89806d49

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40
  Stats: 9494 lines in 81 files changed: 9395 ins; 29 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From prr at openjdk.org  Thu Feb 23 22:24:05 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Feb 2023 22:24:05 GMT
Subject: <i18n dev> RFR: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
In-Reply-To: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
References: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
Message-ID: <sCTjCplB19_cz2WNWGwTsmtVuDBzITpPU1gITAagyNQ=.9122a286-975f-4e5c-87b7-400dfea8a6ad@github.com>

On Sat, 18 Feb 2023 22:18:52 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.
> 
> Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

This change is both un-needed and wrong.

The property is not normally set so GetPropertyAction returns null
Boolean.parseBoolean(null) will return Boolean.FALSE
However the existing code treats null (unspecified) the same as TRUE

So your proposed change breaks apps for no value.

How did you test it ? I see no test here, nor indication that you ran it.

This speaks to how these "harmless" changes can be anything but,
and it takes time and effort to review them for no value to our end-users.

BTW its bizarre to suggest updating this one but not incRate.

However I see no need for this change at all.

So please stop proposing changes that add no value to users and maybe
instead focus on some small test and functional fixes.

-------------

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12639

From duke at openjdk.org  Thu Feb 23 22:29:15 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 22:29:15 GMT
Subject: <i18n dev> RFR: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
In-Reply-To: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
References: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
Message-ID: <jBmrIkGJLars9Js-u9967_xoHqVyJJ6_vkd9EaH4z2E=.b8373098-f399-4a3f-94da-e9e9bbe6cbcf@github.com>

On Sat, 18 Feb 2023 22:18:52 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.
> 
> Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

Oh. Sorry :(

-------------

PR: https://git.openjdk.org/jdk/pull/12639

From duke at openjdk.org  Thu Feb 23 22:29:16 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 22:29:16 GMT
Subject: <i18n dev> Withdrawn: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
In-Reply-To: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
References: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
Message-ID: <79Chu5c3M3N2GE-MF81HZCZQEjRGYNiS0565ZxYsZfs=.530cb342-272f-4b76-89c7-a7235f12c6c1@github.com>

On Sat, 18 Feb 2023 22:18:52 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.
> 
> Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12639

From alanb at openjdk.org  Fri Feb 24 07:31:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:31:08 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v12]
In-Reply-To: <J7Di2ZhG37ghp5kb0_MU7O5FeB41l8k3rXT20sPFQRA=.cc7c2a2b-9427-4553-807f-84e20ab8e304@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>
 <J7Di2ZhG37ghp5kb0_MU7O5FeB41l8k3rXT20sPFQRA=.cc7c2a2b-9427-4553-807f-84e20ab8e304@github.com>
Message-ID: <xa9oE9ty5wrXh0xuHXPxkXZgrvw8PXuoq3eG0PJIYmQ=.27ec1d6e-608c-41a3-ae84-d5f0458d572d@github.com>

On Wed, 22 Feb 2023 18:44:57 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I'll let this linger a bit before integrating in case Alan has comments after the latest updates.

I plan to look at it, been busy with other things.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Fri Feb 24 07:40:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Feb 2023 07:40:10 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v14]
In-Reply-To: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
Message-ID: <6xeTkBjTBcOX__GsKL0hpEnJfSGXRP99acR9Txay9c4=.4206ac5a-f7fc-4366-94db-c143d2547dbe@github.com>

On Wed, 22 Feb 2023 20:01:52 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos 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 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Make the loop variables chars to avoid casting
>  - Use improved case-twiddling comment as suggested by Martin
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>  - Rename unconventionally named local variable 'U' to 'upper'
>  - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
>  - Add whitespace between methods
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/bd4b71f6...597b346a

Thanks, Alan ? Sponsors, hold your horses! (Not sure how to 'undo' the integrate command)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Fri Feb 24 07:56:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:56:10 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <sZ6e3IQf74n8JeZ3jS2RCtNXc3rZVNEhssWPZBF3Syc=.689d0581-f8b8-4d4a-8cbc-bc47868801ba@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Latest version looks good to me, avoids needing stable field or holder class.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12518

From itakiguchi at openjdk.org  Fri Feb 24 08:38:07 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 24 Feb 2023 08:38:07 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Hello @naotoj .
Sorry for bothering you.

I have following question:
- Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
Is there specific reason ?

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Fri Feb 24 11:01:08 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 24 Feb 2023 11:01:08 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <gheAf1iB5AFGkfIwBYGfJdW6VvlIc-OGjuCdRQAoyEw=.7f6710eb-8e4a-4376-816a-f16cd1cc8cef@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Marked as reviewed by coffeys (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Fri Feb 24 11:40:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 11:40:05 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <A2XsV6jvLtc5K_RfoEb1yWVRiSu_TJpgpe0Syc4joek=.a2e0741f-6595-4d05-85b8-00ead2e70cc0@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?

That is a good question. It could move, and $PACKAGE replaced with sun.nio.cs, so it would be more obvious from the source location that it is generated into java.base rather than jdk.charsets. Up until now, GB18030 went into java.base on some platforms and jdk.charsets on other platforms. It will be the same for all platforms once this PR is integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Fri Feb 24 14:36:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 14:36:13 GMT
Subject: <i18n dev> RFR: 8302871: Speed up StringLatin1.regionMatchesCI
 [v14]
In-Reply-To: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
Message-ID: <r66iRYFUQd-sJP_PpnTqWSBt2NX90oTVqbUtI4x8uqU=.974f1434-b6cb-4db5-9247-a2fb0ed5ce14@github.com>

On Wed, 22 Feb 2023 20:01:52 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos 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 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Make the loop variables chars to avoid casting
>  - Use improved case-twiddling comment as suggested by Martin
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>  - Rename unconventionally named local variable 'U' to 'upper'
>  - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
>  - Add whitespace between methods
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/6e269b24...597b346a

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From naoto at openjdk.org  Fri Feb 24 17:23:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:25 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Failed to add the file itself
 - Changed GB18030 from extcs template to stdcs source

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/4d4015a9..9732e6c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Fri Feb 24 17:23:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:26 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Hello @naotoj . Sorry for bothering you.
> 
> I have following question:
> 
> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>   Is there specific reason ?

No, there is not. Thanks for pointing it out. Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From lancea at openjdk.org  Fri Feb 24 18:14:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:14:09 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
Message-ID: <NCWMZuJeSCZIJ64fwTHe2VgNC01TtAaxVGeRj8fh-x4=.8249b760-5221-4dfe-96bc-30672a3934c2@github.com>

On Fri, 24 Feb 2023 17:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Failed to add the file itself
>  - Changed GB18030 from extcs template to stdcs source

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jlu at openjdk.org  Fri Feb 24 18:27:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 18:27:30 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v2]
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Doc adjustments, fix method name in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12269/files
  - new: https://git.openjdk.org/jdk/pull/12269/files/6df5c168..b2c08e1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=00-01

  Stats: 10 lines in 3 files changed: 3 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From naoto at openjdk.org  Fri Feb 24 18:31:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 18:31:13 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v2]
In-Reply-To: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
Message-ID: <uim67-xLTmMq_Mvk1D4dpZ-NvUX4gRm3QP6J9KWofKY=.0fe2cc7d-a691-4dd9-b59f-198a859db576@github.com>

On Fri, 24 Feb 2023 18:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments, fix method name in test

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Fri Feb 24 18:36:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:36:13 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v2]
In-Reply-To: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
Message-ID: <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>

On Fri, 24 Feb 2023 18:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments, fix method name in test

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:

> 153:      * that are provided by each provider, including the JRE.
> 154:      *
> 155:      * @return a stream of the available locales for all provider classes

Seems weird to have the @return where you moved it to

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From naoto at openjdk.org  Fri Feb 24 18:46:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 18:46:13 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v2]
In-Reply-To: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
Message-ID: <djI8beXFqYHTUAXYKIsvtLlGwXEeQzjSkFyDAnYO_YM=.d2b3965d-2ebb-4c9a-9663-27747e1c56e8@github.com>

On Fri, 24 Feb 2023 18:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments, fix method name in test

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 153:

> 151:      * {@return a stream of the available locales for all provider classes}
> 152:      *
> 153:      * Returns a stream of available locales for all the provider classes.

This line can be removed

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Fri Feb 24 18:46:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 18:46:16 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v2]
In-Reply-To: <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
Message-ID: <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>

On Fri, 24 Feb 2023 18:33:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc adjustments, fix method name in test
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:
> 
>> 153:      * that are provided by each provider, including the JRE.
>> 154:      *
>> 155:      * @return a stream of the available locales for all provider classes
> 
> Seems weird to have the @return where you moved it to

>From what I saw in other methods, `@return ...` goes on the bottom (like the line I removed), but the javadoc 16 tag `{@return ... }` goes on the top.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Fri Feb 24 18:51:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 18:51:44 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v3]
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <XYRPIOUKtpHEtoygnBkKpBrB_RcDsjs4X6U-mwu-9K8=.574c661e-e52a-4c20-becc-8d227f7ba51b@github.com>

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Description return no longer needed with {@return ...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12269/files
  - new: https://git.openjdk.org/jdk/pull/12269/files/b2c08e1c..b4d0ceff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Fri Feb 24 19:01:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 19:01:15 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v3]
In-Reply-To: <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
Message-ID: <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>

On Fri, 24 Feb 2023 18:39:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:
>> 
>>> 153:      * that are provided by each provider, including the JRE.
>>> 154:      *
>>> 155:      * @return a stream of the available locales for all provider classes
>> 
>> Seems weird to have the @return where you moved it to
>
> From what I saw in other methods, `@return ...` goes on the bottom (like the line I removed), but the javadoc 16 tag `{@return ... }` goes on the top.

OK but then we should be consistent and update all of the methods to use the new tag or  revert the change for consistency

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From duke at openjdk.org  Fri Feb 24 19:38:05 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 24 Feb 2023 19:38:05 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider
In-Reply-To: <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>
Message-ID: <ZLpBWLQj05Tk2GPz-mg6tIQQPmIOPZPPpFdh4Fg_f6s=.0aa35cd6-dd99-4c89-a787-46acb436108c@github.com>

On Wed, 22 Feb 2023 20:41:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 123:
> 
>> 121:         ZoneRulesProvider.registerProvider(provider);
>> 122:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + zone);
>> 123:         assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should be obtainable");
> 
> If the `zone` does not exist, it will not return `null` but throw an exception. Assertion needs to be modified correctly.

Which version of TestNG is used for JDK? In JUnit 5 I would just use `assertDoesNotThrow()` in such a case but TestNG seems to lack such method.

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Fri Feb 24 19:52:59 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 24 Feb 2023 19:52:59 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v2]
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <tE5pT06KucRru80f2pLZD84cnmv8qdAQRMLDMgcU_EE=.c84fb5f0-30b7-43a2-8080-784aec23f6d5@github.com>

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Madjosz has updated the pull request incrementally with one additional commit since the last revision:

  apply review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12690/files
  - new: https://git.openjdk.org/jdk/pull/12690/files/e87cfef8..0c7e5889

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=00-01

  Stats: 71 lines in 1 file changed: 31 ins; 33 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Fri Feb 24 19:53:02 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 24 Feb 2023 19:53:02 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v2]
In-Reply-To: <ZLpBWLQj05Tk2GPz-mg6tIQQPmIOPZPPpFdh4Fg_f6s=.0aa35cd6-dd99-4c89-a787-46acb436108c@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>
 <ZLpBWLQj05Tk2GPz-mg6tIQQPmIOPZPPpFdh4Fg_f6s=.0aa35cd6-dd99-4c89-a787-46acb436108c@github.com>
Message-ID: <nJteZ8aIZU4lrM3kcvgpmwvqftxu1IFjQN0j_QmHW-A=.0ce2fb0e-947f-485c-974d-2defa923d3fd@github.com>

On Fri, 24 Feb 2023 19:35:29 GMT, Madjosz <duke at openjdk.org> wrote:

>> test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 123:
>> 
>>> 121:         ZoneRulesProvider.registerProvider(provider);
>>> 122:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + zone);
>>> 123:         assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should be obtainable");
>> 
>> If the `zone` does not exist, it will not return `null` but throw an exception. Assertion needs to be modified correctly.
>
> Which version of TestNG is used for JDK? In JUnit 5 I would just use `assertDoesNotThrow()` in such a case but TestNG seems to lack such method.

I just removed the non-`null` assertion as the fact that the call succeeds already is the thing we want to test here.

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From naoto at openjdk.org  Fri Feb 24 21:55:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 21:55:07 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v2]
In-Reply-To: <tE5pT06KucRru80f2pLZD84cnmv8qdAQRMLDMgcU_EE=.c84fb5f0-30b7-43a2-8080-784aec23f6d5@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <tE5pT06KucRru80f2pLZD84cnmv8qdAQRMLDMgcU_EE=.c84fb5f0-30b7-43a2-8080-784aec23f6d5@github.com>
Message-ID: <nRaMUPPLhtiRx8yWeVSv3VgEtR6A8BZtfEr6I-EE9-0=.351d7fab-aaa8-438e-9dd9-abed13b5d2f0@github.com>

On Fri, 24 Feb 2023 19:52:59 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review comments

Changes requested by naoto (Reviewer).

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 107:

> 105: 
> 106:         // availability check
> 107:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + id);

Did you actually run the test??? It still does not compile. Please make sure you run the test under the modified jdk and passes.


STDERR:

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From jlu at openjdk.org  Fri Feb 24 22:00:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 22:00:21 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v3]
In-Reply-To: <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
Message-ID: <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>

On Fri, 24 Feb 2023 18:58:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> From what I saw in other methods, `@return ...` goes on the bottom (like the line I removed), but the javadoc 16 tag `{@return ... }` goes on the top.
>
> OK but then we should be consistent and update all of the methods to use the new tag or  revert the change for consistency

Makes sense, will look at both Locale and LocaleServiceProviderPool and update the methods that are applicable for {@return ..}. Thanks Lance

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From rriggs at openjdk.org  Fri Feb 24 22:13:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Feb 2023 22:13:17 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v3]
In-Reply-To: <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
 <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
Message-ID: <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>

On Fri, 24 Feb 2023 21:57:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> OK but then we should be consistent and update all of the methods to use the new tag or  revert the change for consistency
>
> Makes sense, will look at both Locale and LocaleServiceProviderPool and update the methods that are applicable for {@return ..}. Thanks Lance

That's getting a bit far afield of the original issue; a separate issue might be a better way to address those cases. $.02

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From duke at openjdk.org  Sat Feb 25 00:07:45 2023
From: duke at openjdk.org (Madjosz)
Date: Sat, 25 Feb 2023 00:07:45 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v3]
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <TdzFe2DcY9xBD-ckKlwKYcNdT-bpMDfwgx6sxCDfIYw=.26f261c1-8238-44ed-ad87-ee9d75c96ad1@github.com>

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Madjosz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  apply review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12690/files
  - new: https://git.openjdk.org/jdk/pull/12690/files/0c7e5889..1bcf7bd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Sat Feb 25 07:51:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Feb 2023 07:51:16 GMT
Subject: <i18n dev> Integrated: 8302871: Speed up
 StringLatin1.regionMatchesCI
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <sAOHqzH7pSfMiHXIbqllTRq5Ck5rSaEanQguuNGysgY=.34d5df7a-d0ab-4761-89b9-58651a5f5771@github.com>

On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos <duke at openjdk.org> 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. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

This pull request has now been integrated.

Changeset: 17e3769e
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17e3769ed7190c3ba885e6434e1811bca2d66f13
Stats:     166 lines in 4 files changed: 148 ins; 5 del; 13 mod

8302871: Speed up StringLatin1.regionMatchesCI

Reviewed-by: redestad, martin, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From aturbanov at openjdk.org  Sat Feb 25 18:15:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 18:15:05 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v3]
In-Reply-To: <TdzFe2DcY9xBD-ckKlwKYcNdT-bpMDfwgx6sxCDfIYw=.26f261c1-8238-44ed-ad87-ee9d75c96ad1@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <TdzFe2DcY9xBD-ckKlwKYcNdT-bpMDfwgx6sxCDfIYw=.26f261c1-8238-44ed-ad87-ee9d75c96ad1@github.com>
Message-ID: <dLZwe8IiDv6NwROACiF9q5xFR2AB8dZLf9YcW1VHO0E=.40fadf2f-c3a4-4291-9418-b9367fbfd12c@github.com>

On Sat, 25 Feb 2023 00:07:45 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   apply review comments

src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 319:

> 317:             ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider);
> 318:             if (old != null) {
> 319:                 if(!old.equals(provider)) {

Suggestion:

                if (!old.equals(provider)) {

src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 322:

> 320:                     // restore old state
> 321:                     ZONES.put(zoneId, old);
> 322:                     provider.provideZoneIds().stream()

Can we drop `.stream()` call and just call `.forEach` directly?

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From itakiguchi at openjdk.org  Sun Feb 26 04:39:17 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 26 Feb 2023 04:39:17 GMT
Subject: <i18n dev> RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
 <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
Message-ID: <7dEDXuB8aO0XFkF9AaUZwP9chbjr5RFzvz1mYZnIx4g=.5ef6ecc2-829e-4c97-a662-4a51768ab994@github.com>

On Fri, 24 Feb 2023 17:19:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> Sorry for bothering you.
>> 
>> I have following question:
>> - Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>> I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>> Is there specific reason ?
>
>> Hello @naotoj . Sorry for bothering you.
>> 
>> I have following question:
>> 
>> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>>   Is there specific reason ?
> 
> No, there is not. Thanks for pointing it out. Fixed.

Thanks @naotoj .
That's what I expected.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jlaskey at openjdk.org  Mon Feb 27 12:47:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 12:47:03 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Tighten up reporting of string template errors (fewer messages)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/89806d49..85cc7efc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40-41

  Stats: 52 lines in 5 files changed: 27 ins; 7 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From naoto at openjdk.org  Mon Feb 27 16:39:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Feb 2023 16:39:25 GMT
Subject: <i18n dev> Integrated: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <qgQlYhYos9HSO_KWfSk8FPX1pxdfch9VwquZcrsxiSc=.f6660687-b56d-464c-9e7b-5c349df3b46e@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

This pull request has now been integrated.

Changeset: a253b460
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a253b4602147633a3d2e83775d1feef4f12a5272
Stats:     273 lines in 14 files changed: 117 ins; 41 del; 115 mod

8301119: Support for GB18030-2022

Reviewed-by: alanb, coffeys, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jlu at openjdk.org  Mon Feb 27 17:37:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Feb 2023 17:37:48 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v4]
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Switch {@return for @return for consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12269/files
  - new: https://git.openjdk.org/jdk/pull/12269/files/b4d0ceff..3995a038

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=02-03

  Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Mon Feb 27 17:37:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Feb 2023 17:37:51 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v4]
In-Reply-To: <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
 <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
 <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>
Message-ID: <DUv0DU3rJyskYi1DeUT0lpLe6uYA2vyK9--gqqfS1lw=.1fb90dbc-959f-4602-9355-7b9082e1a474@github.com>

On Fri, 24 Feb 2023 22:10:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Makes sense, will look at both Locale and LocaleServiceProviderPool and update the methods that are applicable for {@return ..}. Thanks Lance
>
> That's getting a bit far afield of the original issue; a separate issue might be a better way to address those cases. $.02

Hi Lance and Roger, I have switched the tag {@return to @return for consistency. And like you proposed Roger, I will open a separate issue to address converting the tags.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Mon Feb 27 17:43:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Feb 2023 17:43:13 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v4]
In-Reply-To: <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
Message-ID: <XJi-0xk7rq2dZCmiT737s58uCZK3jauN0MW6YmJZcCM=.dc883e26-e33f-4500-966c-fdf8eb2704a6@github.com>

On Mon, 27 Feb 2023 17:37:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch {@return for @return for consistency

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Mon Feb 27 17:43:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Feb 2023 17:43:15 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v4]
In-Reply-To: <DUv0DU3rJyskYi1DeUT0lpLe6uYA2vyK9--gqqfS1lw=.1fb90dbc-959f-4602-9355-7b9082e1a474@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
 <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
 <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>
 <DUv0DU3rJyskYi1DeUT0lpLe6uYA2vyK9--gqqfS1lw=.1fb90dbc-959f-4602-9355-7b9082e1a474@github.com>
Message-ID: <ycDYE-H7zpxGkJkkvisXUSYuR1rWrxgSzRrdVhxj9DI=.4a10a4ea-2ecc-45ea-821e-8a91cd44d821@github.com>

On Mon, 27 Feb 2023 17:32:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Hi Lance and Roger, I have switched the tag {@return to @return for consistency. And like you proposed Roger, I will open a separate issue to address converting the tags.

Thank you Justin

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From rriggs at openjdk.org  Mon Feb 27 18:09:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 18:09:31 GMT
Subject: <i18n dev> RFR: 8282319: java.util.Locale method to stream
 available Locales [v4]
In-Reply-To: <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
Message-ID: <JZ-hfshlj8g7BG3DsnhTVx-zIgL_2EnvAW3mYNi7qwU=.dd409c06-d692-4291-8232-059bd68355d9@github.com>

On Mon, 27 Feb 2023 17:37:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch {@return for @return for consistency

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From duke at openjdk.org  Tue Feb 28 07:49:17 2023
From: duke at openjdk.org (Madjosz)
Date: Tue, 28 Feb 2023 07:49:17 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v4]
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Madjosz has updated the pull request incrementally with one additional commit since the last revision:

  whitespace, remove stream()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12690/files
  - new: https://git.openjdk.org/jdk/pull/12690/files/1bcf7bd8..fa728668

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Tue Feb 28 09:44:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 09:44:00 GMT
Subject: <i18n dev> RFR: 8302872: Speed up StringLatin1.regionMatchesCI_UTF16
Message-ID: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>

This PR continues the efforts from #12632 to speed up case-insensitive string matching.

We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`

Key insights:

- If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
- There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
- To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
 
For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   

To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.

Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

-------------

Commit messages:
 - Inline local variable
 - latin1CaseFold was moved to CharacterDataLatin1
 - Move latin1CaseFold to CharacterDataLatin1
 - Improve latin1CaseFold javadocs
 - Simplify comments
 - Prefer fast matching by comparing for equality before checking latin1 range
 - Improve Javadocs of latin1CaseFold
 - Be consistent in comments
 - CharacterData.latin1LowerCase was renamed to latin1CaseFold
 - Hoist equality check out of CharacterDataLatin1.equalsIgnoreCase
 - ... and 13 more: https://git.openjdk.org/jdk/compare/f2b03f9a...92755920

Changes: https://git.openjdk.org/jdk/pull/12637/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302872
  Stats: 169 lines in 5 files changed: 155 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12637/head:pull/12637

PR: https://git.openjdk.org/jdk/pull/12637

From duke at openjdk.org  Tue Feb 28 09:44:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 09:44:02 GMT
Subject: <i18n dev> RFR: 8302872: Speed up
 StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
References: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
Message-ID: <pX_gO_-6yujPk_iElIdqX58A9R0MNgPtW34D8vYgFcE=.8e0eefeb-32d6-44fb-916c-c87774e0ffb9@github.com>

On Sat, 18 Feb 2023 18:22:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR continues the efforts from #12632 to speed up case-insensitive string matching.
> 
> We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`
> 
> Key insights:
> 
> - If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
> - There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
> - To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
>  
> For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   
> 
> To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.
> 
> Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

Benchmark results:

Baseline:


Benchmark                                 (codePoints)  (size)  Mode  Cnt      Score     Error  Units
RegionMatchesIC.Mixed.regionMatchesIC      ascii-match    1024  avgt   15   1497.391 ?  22.350  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   ascii-mismatch    1024  avgt   15      5.346 ?   0.165  ns/op
RegionMatchesIC.Mixed.regionMatchesIC     number-match    1024  avgt   15    364.034 ?   5.561  ns/op
RegionMatchesIC.Mixed.regionMatchesIC  number-mismatch    1024  avgt   15      4.036 ?   0.171  ns/op
RegionMatchesIC.Mixed.regionMatchesIC       lat1-match    1024  avgt   15   2674.043 ? 174.669  ns/op
RegionMatchesIC.Mixed.regionMatchesIC    lat1-mismatch    1024  avgt   15      6.493 ?   0.230  ns/op
RegionMatchesIC.Mixed.regionMatchesIC      utf16-match    1024  avgt   15  12630.314 ? 212.472  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   utf16-mismatch    1024  avgt   15     14.796 ?   0.359  ns/op



PR:


Benchmark                                 (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Mixed.regionMatchesIC      ascii-match    1024  avgt   15  1449.499 ? 14.350  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.450 ?  0.082  ns/op
RegionMatchesIC.Mixed.regionMatchesIC     number-match    1024  avgt   15   362.582 ?  2.963  ns/op
RegionMatchesIC.Mixed.regionMatchesIC  number-mismatch    1024  avgt   15     3.259 ?  0.021  ns/op
RegionMatchesIC.Mixed.regionMatchesIC       lat1-match    1024  avgt   15  1625.513 ? 14.305  ns/op
RegionMatchesIC.Mixed.regionMatchesIC    lat1-mismatch    1024  avgt   15     3.858 ?  0.027  ns/op
RegionMatchesIC.Mixed.regionMatchesIC      utf16-match    1024  avgt   15  1422.722 ? 85.581  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   utf16-mismatch    1024  avgt   15     3.756 ?  0.089  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12637