Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

@oracle.com wrote: Hi Peter, You are correct. Thanks. I'll remove that initial value of 16. Naoto On 5/5/20 9:37 AM, Peter Levart wrote: Hi Naoto, On 4/30/20 12:18 AM, naoto.s...@oracle.com wrote: Hello, Please review this small fix to the following issue: https://bugs.openjdk.java.

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

a/JDK does in floating point before conversion to int. If I put Naoto's formula into my test program, no undercalculations are detected. So while Naoto's formula is sub-optimal for expectedSizes that are multiples of 3, the Guava/JDK also has a bug. Regards, Peter On 5/5/20 10

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

that is less than alternative formula's value and too small to adequately pre-size the HashMap table. Voila, we have some bugs to fix or I am doing something wrong here. Regards, Peter On Tue, May 5, 2020 at 12:12 PM Peter Levart <mailto:peter.lev...@gmail.com>> wrote:

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

> Hi Peter, > > You are correct. Thanks. I'll remove that initial value of 16. > > Naoto > > On 5/5/20 9:37 AM, Peter Levart wrote: >> Hi Naoto, >> >> On 4/30/20 12:18 AM, naoto.s...@oracle.com <mailto:naoto

Re: [15] RFR: 8244152: Remove unnecessary hash map resize in LocaleProviderAdapters

Hi Naoto, On 4/30/20 12:18 AM, naoto.s...@oracle.com wrote: Hello, Please review this small fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8244152 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ The hash map used there didn't

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Thanks Naoto, Alan, David and Venkat. The change is in. Regards, Peter Naoto Sato je 11. 12. 2017 ob 19:41 napisal: Hi Peter, Thanks for the tests. Looks good to me. One nit: it should throw an Exception instead of AssertionError when the test fails. No further review is needed. > Can this

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

thread "main" java.lang.AssertionError: 1180 fatal data races detected     at SimpleTimeZoneCloneRaceTest.main(SimpleTimeZoneCloneRaceTest.java:86) With patch applied, there are no failures of course. Can this go into JDK 10 ? Regards, Peter Naoto On 12/6/17 6:10 AM, Peter Levart

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

oring this patch. Is there anything else that needs to be done from my end for this patch to be integrated? Please let me know. -Venkat On 14/11/17 8:46 PM, Peter Levart wrote: Hi Venkat, I created the following issue: https://bugs.openjdk.java.net/browse/JDK-8191216 I can also sponsor

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

semantics issue of clearCache. You are right. There's some semantics change in clearCache(ClassLoader). Let me look into it. The format field-related changes look good to me. Thanks, Masayoshi On 8/1/2016 11:10 PM, Peter Levart wrote: Hi Masayosh, Alan, Thanks for looking at the chang

Re: ResourceBundleProvider(s) design

On 08/04/2016 11:21 AM, Peter Levart wrote: If the providing module declares the service type, then the consuming module will have an explicit dependency on the providing module, which also defeats the purpose of service provider's implicit coupling. I take this back. The service ty

ResourceBundleProvider(s) design

Hi, I would like to ask about why java.util.spi.ResourceBundleProvider is designed they way it is. I'm questioning the design of the following part of specification: "The provider service type is determined by {@code basename+"Provider"}." Why is that necessary? It requires that provid

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

s to be able to unload the app's class loader. With my proposed change to caching it is not a requirement any more. Regards, Peter On 07/25/2016 08:08 AM, Masayoshi Okutsu wrote: Hi Peter, The change (ResourceBundle part) looks very good to me. There's a simple workaround for th

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

On 07/22/2016 10:46 AM, Peter Levart wrote: Hi Masayoshi, Here's a preview of work to migrate ResourceBundle caching to using ClassLoaderValue utility: http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/ The changes are very straightforward. They preserv

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

en't had a chance. Thanks, Masayoshi On 7/21/2016 10:13 PM, Peter Levart wrote: Hi Masayoshi, Previously the CacheKey::clone() method cleared a reference to 'providers' in the clone making the provides unreachable from the clone and making the clone unable to obtain providers

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

Hi Masayoshi, Previously the CacheKey::clone() method cleared a reference to 'providers' in the clone making the provides unreachable from the clone and making the clone unable to obtain providers. Now you also reset the 'providersChecked' flag which makes the clone be able to re-obtain the p

Re: RFR JDK-7071819: To support Extended Grapheme Clusters in Regex

Regards, Peter On 02/03/2016 12:07 PM, Peter Levart wrote: Hi Sherman, I don't currently have any idea how to squeeze the hashtable any more further. It is already very compact in my opinion. But I noticed a data race that could result in navigating the half-initialized data struct

Re: RFR JDK-7071819: To support Extended Grapheme Clusters in Regex

Hi Sherman, I don't currently have any idea how to squeeze the hashtable any more further. It is already very compact in my opinion. But I noticed a data race that could result in navigating the half-initialized data structure. It is a classical unsafe publication bug. It has been present bef