On 2/6/18 12:13 AM, David Holmes wrote:
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?
I think the thread dumps only the actual JavaThread which is not
"hidden_from_view". There are lots of threads but they're all GC and
compiler threads when I ran this test.
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 was another one of the failures modes, so we need this change to
make this test more reliable.
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. ?
So, looking at and debugging the runtimeService.cpp code, it appears to
be doing the thing that it's supposed to be doing. I agree that it's
not a particularly useful test when changing the times to zero, although
I traced through and it does exercise the code, and logging makes it
non-zero.
What you're suggesting would be a lot more work. I guess my work was to
get the test off the ProblemList.txt but if you'd prefer doing more
work, I'll reassign it and withdraw this RFR. I thought getting it
running without failure is more worth doing than writing a new test for
this feature honestly.
thanks,
Coleen
Thanks,
David
Thanks,
Coleen
