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