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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
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
