Storing both "fasttime" and time in Ticks and Tickspan

[Thomas Schatzl]

Hi all,

  storing of timestamps or durations in gc code is pretty messed up,
almost every collector uses its own data type and time resolution to
store time stamps and durations.

In the past this caused us quite a few headaches when somebody
accidentally stored the durations in variables meant for time stamps
and vice versa, or added together time stamps and durations.

So I was looking into unifying this a bit, and found that JFR did
better than gc code, by having the Ticks and Tickspan types.

When looking at the code that for some reason I would like to ask
about, if JFR is compiled in, they contain fields for a "regular"
(monotonic) time and a "fast" time.

I understand the difference and the reasons to some degree, but the
question I have is whether storing both is actually necessary?

All (JFR) code always uses either one or another, and if one is enabled
the other seems to be never read from from code using them.

Actually if fasttime is disabled, the fasttime value is not updated;
strangely the "regular" time is always updated, regardless of whether 
it's enabled or not.
Further, if JFR is not enabled in the build (compiled out), JFR always
uses the "regulr" time, so it seems to be available anyway.

In a first change to change the timebase for G1 (and ZGC uses it
throughout already), I started using Ticks/Tickspan everywhere, but I
would like to ask about the reason of 

- storing both values (fast and regular) in the Tickspan/Ticks class
always as it takes extra space for no apparent gain

- and in extension actually ever using the "fast" time as the "regular"
one seems to be always available.

Is the performance advantage of the "fast" time which is only used on
32 bit x86 (non-Zero platforms) worth keeping it? Considering that the
"regular" time is always taken in addition to this "fast" time.

On x86-64 we do not use the "fast" time at all although it should have
the same performance benefits (which are the only benefits I can see).

Any comments?

Thanks,
  Thomas