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

Michal Vala mvala at redhat.com
Mon Feb 11 06:52:24 UTC 2019


Hi Martin,

thank you for reviewing and sponsoring this!

On 2/8/19 10:48 PM, Martin Buchholz wrote:
> 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
>>>
>>
> 

-- 
Michal Vala
OpenJDK QE
Red Hat Czech


More information about the core-libs-dev mailing list