On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman <al...@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
