RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
Alan Bateman
alanb at openjdk.org
Wed Jun 14 13:17:04 UTC 2023
On Tue, 13 Jun 2023 17:57:36 GMT, Naoto Sato <naoto at 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229601286
More information about the core-libs-dev
mailing list