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 10:44:59 PST 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-runtime-dev
mailing list