RFR: 8273239: Standardize Ticks APIs return type

[David Holmes]

On 2/09/2021 10:28 pm, Albert Mingkun Yang wrote:
> On Thu, 2 Sep 2021 10:44:21 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Any changes to these API's should be approved by that team IMO.
> 
> I checked with Markus before sending out this PR.

It would be good if Marcus could review it then.

>> I'm more inclined to expect an API that produces integral values than fractions
> 
> Only `nanoseconds()` can return an integral value without discarding any info. Converting to other units requires some floating calculation; the fractional part is either dropped behind the API (in `master`) or controlled by the caller (in this patch).

I expect there to be "discarded" information. I'm asking for how many 
milliseconds have "elapsed". If I want to know about fractional 
milliseconds I should ask how many microseconds or nanoseconds have 
elapsed instead. When we ask for the current time as "milliseconds since 
the epoch" we expect an integral number at that resolution; the fact 
their could be additional microseconds and nanoseconds is immaterial.

David
-----

>> Converting nanosecond time values to double can be information losing.
> 
> True. Such loss comes from the following conversion (from `ticks.hpp`). (Note: this kind of loss is different from the one discarding the fractional part on API boundary.)
> 
> 
> template <typename TimeSource, const int unit>
> inline double conversion(typename TimeSource::Type& value) {
>    return (double)value * ((double)unit / (double)TimeSource::frequency());
> }
> 
> 
> I am not sure how significant this loss is in practice; all callers of `seconds()` (the most used API among the four) suffer from this loss.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5332
>