On Tue, 18 Jul 2023 15:11:04 GMT, Chen Liang <li...@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
