Weird, I'm almost sure I attached it (and sure I browsed to attach it). Maybe I clicked on it to look at it, and it removed it.
I send again, with password toto (in case some security software removes attachments with .java files). -Jeff ________________________________ De : Ulf Zibis <ulf.zi...@gmx.de> À : Jeff Hain <jeffh...@rocketmail.com> Cc : Weijun Wang <weijun.w...@oracle.com>; core-libs-dev <core-libs-dev@openjdk.java.net> Envoyé le : Vendredi 18 Novembre 2011 20h45 Objet : Re: Re : what is the most precise time I can get in JDK? Sounds interesting, but there is no attachment ? -Ulf Am 18.11.2011 20:35, schrieb Jeff Hain: > Hi. > > I've had the same need (or desire), and made a ThinTime class for it > (attached). > > Returned time : > - is not much more inaccurate than System.currentTimeMillis(), > - is always ahead of System.currentTimeMillis(), > > - is monotonic (unless System.currentTimeMillis() jumps backward), > > - should change way more often than System.currentTimeMillis(). > > NB: It makes use of "raw" AtomicXXX classes, without cache line padding, > so there is room for optimization here, but maybe you are like me and > prefer to wait on @Contended annotation arrival than plague your code > with unreliable padding magic :) > > > -Jeff > > > ________________________________ > De : Weijun Wang<weijun.w...@oracle.com> > À : David Holmes<david.hol...@oracle.com> > Cc : core-libs-dev<core-libs-dev@openjdk.java.net> > Envoyé le : Mercredi 16 Novembre 2011 9h09 > Objet : Re: what is the most precise time I can get in JDK? > > Hi Davis > > Yes, I know nanoTime() is precise, but how can I get a clock time from > it? I have tried to record a currentTimeMillis() value when the program > starts and then use the elapse of the nanaTime() to get a current time. > This will break if the user adjusts the system clock during the program > execution. > > One solution is to keep tracking the changing of both > currentTimeMillis() and nanoTime(). If the change of one has a > difference (say,> 1 sec) from the other one, it means a system clock > change and I can quickly reset my time to currentTimeMillis(). > > Thanks > Max > > > > On 11/16/2011 03:23 PM, David Holmes wrote: >> Hi Max, >> >> On 16/11/2011 2:55 PM, Weijun Wang wrote: >>> I need a precise time, and is currently using java.util.Date, which knows >>> about milliseconds, but unfortunately the precision is only 10-15 >>> milliseconds on a Windows. >>> >>> In fact, I don't really need it to be so correct. My requirements are: >>> >>> 1. It's enough correct, say, at least as correct as Date. >>> 2. It's precise in a relative sense, i.e. it changes fast >>> 3. It should be monotonic, i.e. it grows, unless the user adjusts the >>> system >>> clock >> There are only two time source available: >> >> 1. The time-of-day clock >> >> This is what Date reports and is also what System.currentTimeMillis >> reports. It only has millisecond precision. It's rate of update is >> dependent on the OS - for Windows that is typically every 10ms or every >> 15ms depending on version. >> >> 2. The high resolution time source >> >> This is what System.nanoTime reports. It has nanosecond precision, but >> again depending on the OS it's resolution (update rate) will vary. The >> update rate should easily be in the tens of microseconds. It should be >> monotonic non-decreasing but it is not connected to the time-of-day >> clock (and so should not be affected by any changes therein). >> >> I have an old blog entry on this: >> >> http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks >> >> David >> -----
