RFR (XS) 8174734: Safepoint sync time did not increase

[David Holmes]

Hi Coleen,

On 6/02/2018 7:37 AM, coleen.phillimore at 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