JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Patrick Zhang patrick at os.amperecomputing.com
Wed Jan 30 04:32:28 UTC 2019

This is a nice patch as I found the same problem back to December. Privately I was using "(size + s > threshold)" condition for my cases, and found Michal's early comment that this would lead to "unwanted space allocation" caused by duplicate keys, thanks.

Looking forward to having this in jdk/jdk trunk.


-----Original Message-----
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf Of Michal Vala
Sent: Tuesday, January 29, 2019 6:00 PM
To: Martin Buchholz <martinrb at google.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi Martin,

I'd like to finish this review. Are you still willing to sponsor this?


On 1/9/19 11:39 AM, Michal Vala wrote:
> ping
> On 1/3/19 9:31 PM, Michal Vala wrote:
>> Hi Martin,
>> can we please finish this review?
>> On 12/19/18 6:32 PM, Michal Vala wrote:
>>> On 12/19/18 4:15 PM, Martin Buchholz wrote:
>>>> On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>> Hi Martin,
>>>>> It is also useful and conventional to print the seed of the random 
>>>>> so that if necessary it can be reproduced.
>>>> For many years, we've been using ThreadLocalRandom for testing, and 
>>>> that does not allow setting a seed.
>>>> I remain unconvinced that saving a seed has value in the real 
>>>> world.  When a randomized test fails, running it with sufficient 
>>>> iterations has always worked for me.
>>> What's the reason behind using ThreadLocalRandom?
>>> In my opinion, reproducing the issue is key. One failure of 
>>> randomized test run might be caused by one issue, second run due to 
>>> another issue. How we reproduce then and how we know even how many 
>>> issues we have? When we're running random tests until it pass, it might even hide the issue.
>>> They sure have good value on reveal the issue, but then we have to 
>>> know how to reproduce and what we're searching for.
>>> If this case would not require ThreadLocalRandom and Random is 
>>> enough, I'd like to use that because of benefits I've mentioned.

Michal Vala
Red Hat Czech

More information about the core-libs-dev mailing list