Hi Coleen,
On 6/02/2018 7:37 AM, coleen.phillim...@oracle.com wrote:
Summary: allow safepoint time to be zero in the test
See bug for more details.
open webrev at http://cr.openjdk.java.net/~coleenp/8174734.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8174734
I guess I'm still surprised that 300 thread dumps can take less than a
millisecond! There's always more than one thread running. I did some
basic benchmarking and dumpAllStacks() from main takes at least 150us on
the Linux box I tested on. I just can't see 300 dumps taking less than
1ms ... though I can see them taking < 10ms if we're measuring time
using a coarse clock - where do these times come from?
That aside this change seem unnecessary:
// Careful with these values.
! private static final long MIN_VALUE_FOR_PASS = 0;
private static final long MAX_VALUE_FOR_PASS = Long.MAX_VALUE;
this is for the minimum number of safepoints that need to be seen, which
I think should still be 1. By allowing 0 here (and for the elapsed
time), the test could actually fail to do anything related to safepoints
and still pass - and that seems wrong. Or the safepoint stat code could
be completely broken and we'd never notice. Basically the test just
wants to check that we get reasonable looking statistics from the MBean
Maybe we need to be measuring the time at a higher resolution than
milliseconds - though that would be a non-trivial RFE I expect. ?
Thanks,
David
Thanks,
Coleen
