and ... finally committed (sorry as always for the sloth pace) On Wed, Feb 6, 2019 at 10:28 AM Martin Buchholz <marti...@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 <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 >> >
