<i18n dev> RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]

[Naoto Sato]

On Tue, 18 Jul 2023 15:11:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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 14 additional commits since the last revision:
>> 
>>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>>  - Use ReferencedKeyMap in place for LocaleObjectCache
>>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>>  - Addressing review comments
>>  - Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>>  - minor comment fix
>>  - equals/hash fix, constructor simplification
>>  - Removed Key
>>  - minor fixup
>>  - Use WeakHashMap
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/b7933f62...870ec1fe
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 167:
> 
>> 165:         // can subsequently be used by the Locale instance which
>> 166:         // guarantees the locale components are properly cased/interned.
>> 167:         return CACHE.computeIfAbsent(new BaseLocale(language, script, region, variant),
> 
> This `computeIfAbsent` will store the non-normalized base locale as a soft key in the cache, which is undesirable. I have commented on the base patch https://github.com/openjdk/jdk/pull/14684#discussion_r1266914091 to support distinct keys for querying and storing like those in the old `LocalObjectCache`, and we can then simply use a `ReferenceKeySet` for the cache.

The reason I used non-normalized base locale as the key was that normalizing (interning) was slower than comparing the key. I would have to double check, and see if the distinct normalized key is faster.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1267037551