RFR: 8273239: Standardize Ticks APIs return type

[Markus Gronlund]

Hi Albert,

As we talked a little bit offline, IIRC the reason for providing these return types was because it was modelled it on the precedences in runtime/os.hpp:

  static jlong  javaTimeMillis();
  static jlong  javaTimeNanos();
  static void   javaTimeNanos_info(jvmtiTimerInfo *info_ptr);
  static void   javaTimeSystemUTC(jlong &seconds, jlong &nanos);
  static void   run_periodic_checks();
  // Returns the elapsed time in seconds since the vm started.
  static double elapsedTime();
  static jlong elapsed_counter();

Since I don't have any call sites that use the Ticks conversion methods, which I mostly think is used by the GC code, and I do not remember the exact reasoning, I thought your standardizing effort for "double" to be ok.

But now I think that David and others have brought good arguments to this PR highlighting benefits in having the sub-second representations as integrals, so I now believe we should perhaps keep the return types as is.

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?

Thanks
Markus

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of David Holmes
Sent: den 2 september 2021 15:19
To: Albert Mingkun Yang <ayang at openjdk.java.net>; hotspot-dev at openjdk.java.net
Subject: Re: RFR: 8273239: Standardize Ticks APIs return type

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
>