[UNVERIFIED SENDER] RE: RFR: 8273239: Standardize Ticks APIs return type

[Hohensee, Paul]

I haven't been following this thread, so please forgive redundancy.

For the fully concurrent collectors such as Shenandoah, ZGC, and C4, we want to be able to measure intervals that may be shorter than a millisecond. Azul uses seconds-as-doubles to do this in their MXBean APIs (see https://docs.azul.com/prime/MXBeans), but given that Hotspot has access to nanotime counters and that a long can hold ~272 years of nanoseconds, I'd very much like for Hotspot to standardize on nanoseconds internally and make millis and seconds available as convenience methods.

Parenthetically, we're working on a merge of Azul's MXBeans into com.sun.management MXBeans for the purpose of monitoring concurrent collectors, in our case Shenandoah. Azul has been using their interface in production for at least a decade, which is the primary reason we're using their paradigm. The new APIs are a strict superset of what's there, and it's looking like it should be no problem to integrate support for non-concurrent collectors. We've gone with the above scheme and standardized on nanos with millis and seconds as convenience methods.

Thanks,
Paul

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> on behalf of Markus Gronlund <markus.gronlund at oracle.com>
Date: Thursday, September 2, 2021 at 7:45 AM
To: David Holmes <david.holmes at oracle.com>, Albert Mingkun Yang <ayang at openjdk.java.net>, "hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>
Subject: [EXTERNAL] [UNVERIFIED SENDER] RE: RFR: 8273239: Standardize Ticks APIs return type

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



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
>