RFR (M): 8235741: Inappropriate uses of os::javaTimeMillis()

[David Holmes]

webrev: http://cr.openjdk.java.net/~dholmes/8235741/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8235741

Full details in the bug report about the existing uses of 
javaTimeMillis(), many of which just want an elapsed time in ms and so 
should be using javaTimeNanos() and convert to ms. This covers areas all 
across the VM.

Only non-simple change is in os_perf_linux.cpp (and the same code will 
be in os_perf_aix.cpp once it has been validated). There we are tracking 
an elapsed time in ms but relative to the boot time, which is seconds 
since the epoch. Consequently the first interval has to be calculated 
using javaTimeMillis, but after that we can use javaTimeNanos (using a 
new 'first time' captured at the same time we used javaTimeMillis). I 
think I have the logic right but other than through JFR this code seems 
unused and I have limited means of testing it. The JFR test 
jdk/jfr/event/os/TestThreadContextSwitches.java exercises the code but 
the results of running that test seems to exhibit arbitrary randomness 
in the rates reported - e.g. 0 to 16000Hz - both with and without my 
change, so not really that useful. Stefan K. suggested a gtest which I 
may look into - though it is frustrating to have to expend such effort 
to validate this.

Other testing tiers 1-3.

Thanks,
David