usage of System.currentTimeMillis();

[Mark Struberg]

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

[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>

Post by Mark Struberg
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]

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.

Post by 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

Post by Mark Struberg
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,

Post by Mark Struberg
etc).b.) on Linux currentTimeMillis might be way more expensive than
System.nanoTime(); Mainly depending on whether the underlying HPET is

used

Post by Mark Struberg
(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