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

naoto.sato at oracle.com naoto.sato at oracle.com
Tue May 5 17:25:13 UTC 2020


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.sato at 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 have initial capacity, even though the 
>> exact numbers are known.
> 
> 
> Well, it has to be calculated 1st (countTokens), but I guess this pays 
> off when HashSet (the backing HashMap) does not have to be rehashed then.
> 
> The expression you use:
> 
>      Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16)
> 
> ...has a minimum value of 16. Why is that? 16 is just HashMap's default 
> initialCapacity if not specified explicitly. But if you only want to 
> store say 1 entry in the map, you can specify 2 as initialCapacity and 
> HashMap will happily work for such case without resizing.
> 
> 
> So you could just use:
> 
>      (int)(tokens.countTokens() / 0.75f) + 1
> 
> And even this expression is sometimes overshooting the minimal required 
> value by 1 (when # of tokens is "exact" multiple of 0.75f, say 6). I 
> think the following could be used to optimally pre-size the HashMap with 
> default load factor 0.75:
> 
>      (tokens.countTokens() * 4 + 2) / 3
> 
> 
> Regards, Peter
> 
>>
>> Naoto


More information about the core-libs-dev mailing list