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 
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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 24 oct. 2018 à 13:18, Mark Struberg  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 

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 24 oct. 2018 à 13:18, Mark Struberg  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
>

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