On Wed, 14 Jun 2023 13:29:39 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>>> 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. Jim's `java.lang.runtime.ReferenceKeyMap` would be a possible solution for it, although it is currently package private. But I will need to think about it more as Alan suggests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229857996
