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

[Martin Buchholz]

and ... finally committed
(sorry as always for the sloth pace)

On Wed, Feb 6, 2019 at 10:28 AM Martin Buchholz <martinrb at google.com> wrote:

> Finally got around to doing some work on this.
> I'm happy with this latest revision:
>
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/HashMap-resize/index.html
>
> I did some more work on the microbenchmark, in part to force myself to
> learn about jmh.
> It now tests LinkedHashMap as well.
> I replaced use of Random with ThreadLocalRandom
>
>     @Param("1000000")
>     private int size;
>
>     @Param
>     private MapType mapType;
>
>     public enum MapType {
>         HASH_MAP,
>         LINKED_HASH_MAP,
>     }
>
>
>
> On Thu, Jan 3, 2019 at 12:31 PM Michal Vala <mvala at redhat.com> 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
>> OpenJDK QE
>> Red Hat Czech
>>
>