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

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. >

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,

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 > >

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 > >

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

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

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 > >

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 >

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).