<i18n dev> 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 i18n-dev mailing list