Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/1832
@srdo Sorry I am kind of coming into this half way through.
History: System.nanoTime and System.currentTimeMillis have different uses
and are not on the same time line. nanoTime is guaranteed to be monotonically
increasing so long as the box is up. currentTimeMillis is not, because it is
kept in sync with the system time. currentTimeMillis on most OSes is a very
cheap. It is reading from shared memory, no system call needed. It can be
different if read from different threads even. nanoTime, at least on x86 boxes
end up reading a special register in the processor. If there is a very small
core count this is cheap. However if you are on a system with many different
cores or physical chips they all have to be synced up to guarantee that it is
monotonically increasing so it ends up being about as expensive as a memory
barrier. Not super expensive but also not dead cheap.
As far as Time.java is concerned. Simulated time can be whatever we want.
I don't care if we store nanos internally or millis internally. It is all
simulated anyways. If we are not simulating I don't think we should mix the
two or have one backed by the other. They are separate for a reason and people
most of the time will pick one or the other because of those differences. If
we want nano support then lest have Time support nano, but the milli APIs stay
backed by System.currentTimeMillis, and the nano APIs are backed by
System.nanoTime.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
