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

Martin Buchholz martinrb at google.com
Thu Jan 31 03:15:21 UTC 2019


This one keeps bubbling to the very top of my todo stack, only to be
pre-empted a minute later by some other task.

On Tue, Jan 29, 2019 at 2:00 AM Michal Vala <mvala at redhat.com> wrote:

> 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.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
>


More information about the core-libs-dev mailing list