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

[Martin Buchholz]

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
>