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. Regards Patrick -----Original Message----- From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> On Behalf Of Michal Vala Sent: Tuesday, January 29, 2019 6:00 PM To: Martin Buchholz <marti...@google.com> Cc: core-libs-dev <core-libs-dev@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? Thanks! 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.ri...@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 OpenJDK QE Red Hat Czech
