RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
Brett Okken
duke at openjdk.org
Fri Jun 16 12:14:04 UTC 2023
On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>>
>> (w/o fix)
>>
>> Benchmark Mode Cnt Score Error Units
>> LocaleCache.testForLanguageTag avgt 20 5781.275 ± 569.580 ns/op
>> LocaleCache.testLocaleOf avgt 20 62564.079 ± 406.697 ns/op
>>
>> (w/ fix)
>> Benchmark Mode Cnt Score Error Units
>> LocaleCache.testForLanguageTag avgt 20 4801.175 ± 371.830 ns/op
>> LocaleCache.testLocaleOf avgt 20 60394.652 ± 352.471 ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>
> Addressing review comments
src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
> 173: LocaleUtils.toLowerString(b.getLanguage()).intern(),
> 174: LocaleUtils.toTitleString(b.getScript()).intern(),
> 175: LocaleUtils.toUpperString(b.getRegion()).intern(),
don't lines 147 and 148 above already guarantee the language and region have correct case?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232167067
More information about the hotspot-gc-dev
mailing list