There is no guarantee that it needs to be monotonic - particularly in MP systems - both numa and smp systems : unless you tie each process to a particular core via affinity. nanotime() attempts to do a bestcase effort based on ticks (usually), while currentTimeInMillis is based on clock. Both can drift in unpredictable ways (former due to core/proc changes, latter due to ntp updates usually, etc).
Relying on monotonicity might leads to unpredictable errors :-) Regards, Mridul > -----Original Message----- > From: Ivan Kelly [mailto:[email protected]] > Sent: Thursday, July 05, 2012 8:15 PM > To: [email protected] > Subject: Re: Reg System.currentTimeMillis usage in BookKeeper > > > I agree it is not good to change the system time on a running > process, > > still I'm thinking we can use System.nanoTime(), this will be giving > > the JVM startup time and will helpful to withstand this kind of minor > > accidents(as this came in the stat calculation logic). > > Good idea. Could you open a JIRA for this. > > System.nanoTime() should be monotonic on most systems, whereas > currentTimeMillis() is not guarenteed to be. Apparently, > System.nanoTime() can be non monotonic if the OS doesn't support it, > but in that case it falls back to currentTimeMillis anyhow. > > Performance wise, they seem very similar on linux. currentTimeMillis is > a little quicker, but it's the difference between .66 microseconds and > .7 microseconds. Not worth losing sleep over. > > 100m invokations of nanoTime : 71085070000ns 71085ms 100m invokations > of currentTimeMillis : 66250899000ns 66250ms > > There's an interesting bug report that codes through the monotonicness > issue. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458294 > > > -Ivan
