usage of System.currentTimeMillis();

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

usage of System.currentTimeMillis();

Mark Struberg-2
Hi folks!
While fixing a deadlock in commons-pool I also stumbled across System.currentTimeMillis();quite a few times.It's no biggie but I would still love to get your feedback and experience.
If I remember correctly then one should use Sytem.nanoTime() in those cases.a.) afair currentTimeMIllis() might jump back in time (on NTP syncs, etc).b.) on Linux currentTimeMillis might be way more expensive than System.nanoTime(); Mainly depending on whether the underlying HPET is used (slow) or another timer source.

What is your experience? Is this still correct?Or is this gone with new boards and more recent JVMs?
LieGrue,strub
Reply | Threaded
Open this post in threaded view
|

Re: usage of System.currentTimeMillis();

Romain Manni-Bucau
Hi Mark,

AFAIK currenttimemillis is still "cached" compared to nanotime but for
duration computation nanotime is prefered (whereas when the time must be
aligned on the watch currenttimemillis is the only valid choice).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 24 oct. 2018 à 13:18, Mark Struberg <[hidden email]> a
écrit :

> Hi folks!
> While fixing a deadlock in commons-pool I also stumbled across
> System.currentTimeMillis();quite a few times.It's no biggie but I would
> still love to get your feedback and experience.
> If I remember correctly then one should use Sytem.nanoTime() in those
> cases.a.) afair currentTimeMIllis() might jump back in time (on NTP syncs,
> etc).b.) on Linux currentTimeMillis might be way more expensive than
> System.nanoTime(); Mainly depending on whether the underlying HPET is used
> (slow) or another timer source.
>
> What is your experience? Is this still correct?Or is this gone with new
> boards and more recent JVMs?
> LieGrue,strub
>
Reply | Threaded
Open this post in threaded view
|

Re: usage of System.currentTimeMillis();

Matt Sicker
Java 8 introduced the java.time.Clock class which can be used to customize
this behavior. In Log4j, we have a similar Clock class (from back when we
were on Java 6) which is used instead of System to allow for the user to
customize their performance requirements.

On Wed, 24 Oct 2018 at 07:57, Romain Manni-Bucau <[hidden email]>
wrote:

> Hi Mark,
>
> AFAIK currenttimemillis is still "cached" compared to nanotime but for
> duration computation nanotime is prefered (whereas when the time must be
> aligned on the watch currenttimemillis is the only valid choice).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 24 oct. 2018 à 13:18, Mark Struberg <[hidden email]> a
> écrit :
>
> > Hi folks!
> > While fixing a deadlock in commons-pool I also stumbled across
> > System.currentTimeMillis();quite a few times.It's no biggie but I would
> > still love to get your feedback and experience.
> > If I remember correctly then one should use Sytem.nanoTime() in those
> > cases.a.) afair currentTimeMIllis() might jump back in time (on NTP
> syncs,
> > etc).b.) on Linux currentTimeMillis might be way more expensive than
> > System.nanoTime(); Mainly depending on whether the underlying HPET is
> used
> > (slow) or another timer source.
> >
> > What is your experience? Is this still correct?Or is this gone with new
> > boards and more recent JVMs?
> > LieGrue,strub
> >
>


--
Matt Sicker <[hidden email]>