RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-09 Thread Naoto Sato
This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Albert Mingkun Yang
On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato wrote: > This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Daniel Fuchs
On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato wrote: > This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Daniel Fuchs
On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato wrote: > This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Daniel Fuchs
On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato wrote: > This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Daniel Fuchs
On Mon, 12 Jun 2023 14:26:34 GMT, Daniel Fuchs wrote: > The main change is that base locales will now be cached using WeakReference > rather than SoftReference, and thus probably collected more eagerly, but that > actually looks like a positive change. Hmm or not. Nothing references the ke

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Roger Riggs
On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato wrote: > This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-06-12 Thread Naoto Sato
On Mon, 12 Jun 2023 16:23:29 GMT, Roger Riggs wrote: > One other thing to consider... If the BaseLocale entries are being GC'd > sooner, then perhaps the value of the String.intern() is reduced. Eliminating > `.intern90` would make creating a normalized BaseLocale faster. Some code inside the

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale

2023-11-01 Thread Aleksey Shipilev
On Mon, 12 Jun 2023 17:28:44 GMT, Naoto Sato wrote: >> One other thing to consider... >> If the BaseLocale entries are being GC'd sooner, then perhaps the value of >> the String.intern() is reduced. >> Eliminating `.intern90` would make creating a normalized BaseLocale faster. > >> One other thi

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-12 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-12 Thread Naoto Sato
On Mon, 12 Jun 2023 14:35:15 GMT, Daniel Fuchs wrote: > One thing though - WeakHashMap is not thread safe - and I don't see any locks > or synchronized to protect access to CACHE. Is that going to cause trouble if > two threads compete to add a locale to the map? In other words - how > confide

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-12 Thread Naoto Sato
On Mon, 12 Jun 2023 12:49:05 GMT, Albert Mingkun Yang wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing comments (test grouping, synchronization), minor optimization >> on loop lookup > > test/hotspot/jtreg

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-12 Thread Daniel Fuchs
On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-13 Thread Alan Bateman
On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-13 Thread Andrey Turbanov
On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]

2023-06-13 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-13 Thread Naoto Sato
On Tue, 13 Jun 2023 11:22:11 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing comments (test grouping, synchronization), minor optimization >> on loop lookup > > src/java.base/share/class

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-13 Thread Naoto Sato
On Tue, 13 Jun 2023 13:09:49 GMT, Andrey Turbanov wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing comments (test grouping, synchronization), minor optimization >> on loop lookup > > test/micro/org/openjdk

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-14 Thread Alan Bateman
On Tue, 13 Jun 2023 17:57:36 GMT, Naoto Sato 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

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-14 Thread Daniel Fuchs
On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman 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. > Movin

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-14 Thread Naoto Sato
On Wed, 14 Jun 2023 13:29:39 GMT, Daniel Fuchs 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 ReferenceKeyMa

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]

2023-06-16 Thread Brett Okken
On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]

2023-06-16 Thread Brett Okken
On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]

2023-06-16 Thread Naoto Sato
On Fri, 16 Jun 2023 12:46:01 GMT, Brett Okken wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing review comments > > src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168: > >> 166: //

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]

2023-06-16 Thread Brett Okken
On Fri, 16 Jun 2023 17:18:33 GMT, Naoto Sato wrote: >> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168: >> >>> 166: // BaseLocale as the key. The returned "normalized" instance >>> 167: // can subsequently be used by the Locale instance which >>> 168:

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]

2023-06-16 Thread Brett Okken
On Fri, 16 Jun 2023 17:18:38 GMT, Naoto Sato wrote: >> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175: >> >>> 173: >>> LocaleUtils.toLowerString(b.getLanguage()).intern(), >>> 174: >>> LocaleUtils.toTitleString(b.get

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]

2023-06-29 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]

2023-07-18 Thread Chen Liang
On Thu, 29 Jun 2023 19:28:05 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]

2023-07-18 Thread Naoto Sato
On Tue, 18 Jul 2023 15:11:04 GMT, Chen Liang wrote: >> Naoto Sato has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 14 additional >> commits since

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v5]

2023-08-01 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v5]

2023-08-29 Thread Chen Liang
On Tue, 1 Aug 2023 20:21:11 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer nee

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v5]

2023-08-30 Thread Naoto Sato
On Wed, 30 Aug 2023 06:40:40 GMT, Chen Liang wrote: >> Naoto Sato has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 29 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jdk into >> JDK-8309622-Cache-BaseLocale >>

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v6]

2023-08-30 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v7]

2024-02-21 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v7]

2024-02-22 Thread Naoto Sato
On Thu, 22 Feb 2024 00:14:23 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v8]

2024-02-22 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v9]

2024-02-22 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v10]

2024-03-01 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v11]

2024-03-01 Thread Roger Riggs
On Fri, 1 Mar 2024 21:29:17 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer nee

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v11]

2024-03-01 Thread Naoto Sato
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). A

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v6]

2024-01-04 Thread Naoto Sato
On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v6]

2024-02-01 Thread Naoto Sato
On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer ne