RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic

John Cuthbertson john.cuthbertson at oracle.com
Thu Dec 15 18:44:59 UTC 2011


Hi David,

On 12/12/11 21:28, David Holmes wrote:
> On 13/12/2011 6:06 AM, John Cuthbertson wrote:
>> Thanks for looking at the code changes and for the suggestions.
>>
>> Extending the os API is a good idea. Not sure about the name though -
>> how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp
>> already has an internal monotonic version of javaTimeMillis() so there
>> are alternatives to using javaTimeNanos() in the implementation.
>
> I'm somewhat opposed to extending the API simply because there are 
> already too many time functions. What about a TO_MILLIS macro?
>
> #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC
>
> jlong start = TO_MILLIS(javaTimeNanos());

I'm not a fan of this approach - to me it's just hiding the division and 
is really no different from the posted webrev. I'd rather go with what's 
in the webrev.

>
> BTW the "java" in javaTimeMillis and javaTimeNanos identifies these 
> methods as being part of the Java API (System.currentTimeMillis and 
> System.nanoTime respectively) - so javaMonotonicTimeMillis would not 
> be appropriate.

I see. Thanks for the heads up. No java in the routine name (if it's 
decided that's the best approach).

>
> John: you have a recurrent typo in the comments: monton instead of 
> monoton (and I mistyped it myself writing that!)

OK. Thanks. I correct those.
>
>> Thanks for the heads up about the other CR. I'll check.
>
> See 4741166. It wanted to make javaTimeMillis monotonic, which it can 
> not be. Pretty much all internal uses of javaTimeMillis (those not 
> part of implementing System.currentTimeMillis()) should really be 
> using a monotonic time source.

To achieve that goal - I think an additional routine might be needed 
(say clockTimeMillis_monotonic) but I think a significant portion of the 
calls to javaTimeMillis is outside the scope of this CR.

Unless there's any objection - I'll go with the posted webrev.

Thanks,

JohnC



More information about the hotspot-gc-dev mailing list