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

[Daniel Fuchs]

On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Replaced it with a ReentrantLock
>
>> Replaced it with a ReentrantLock
> 
> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
> 
> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

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

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