RFR: 8273239: Standardize Ticks APIs return type

[Albert Mingkun Yang]

On Thu, 2 Sep 2021 19:05:57 GMT, Hohensee, Paul <hohensee at amazon.com> wrote:

> When we ask for the current time as "milliseconds since the epoch" we expect an integral number at that resolution

I don't think there's an established convention on what the expectation is, integral vs fractional; both scenarios can exist. Taking the expect-for-integral logic to the extreme, one could argue `seconds()` should return `uint64_t` as well.

> Maybe it is possible to approach this instead along the lines suggested by Kim, by introducing a few helper functions to provide floating point values?

Here are my two propositions: (more are welcome)

1. A consistent return type (`double`) for s/ms/us, but not ns. ns is special because it's the only unit without info loss. Callers expect integral values for s/ms/us can easily discard the fractional part.

2. Keep the existing return-type API, and add two more methods for ms/us returning `double`.

Note in both propositions, the implementation of `uint64_t nanoseconds()` will be different from `master`, which performs unnecessary double conversion. The new impl should address Kim's concern of `uint64_t-to-double` info loss.


// option 1
// s/ms/us do the double conversion&calculation
// ns      return the underlying counter

double seconds();
double milliseconds();
double microseconds();
uint64_t nanoseconds();


// option 2
// s     do double conversion&calculation
// ms/us do double conversion&calculation and discard fractional
// ns    return the underlying counter
 
double seconds();
uint64_t milliseconds();
uint64_t microseconds();
uint64_t nanoseconds();

// ms/us do double conversion&calculation
double milliseconds_fractional();
double microseconds_fractional();

-------------

PR: https://git.openjdk.java.net/jdk/pull/5332