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

Robbin Ehn robbin.ehn at oracle.com
Mon Jan 13 13:08:21 UTC 2020


Hi David, looks good, thanks!

/Robbin

On 1/13/20 8:13 AM, David Holmes wrote:
> 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


More information about the hotspot-dev mailing list