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

[Kim Barrett]

> On Sep 3, 2021, at 8:19 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> On 2021-09-02 23:40, Kim Barrett wrote:
>> [resending from the correct account, so it gets to the mailing list and the PR.]
>> 
>>> On Sep 2, 2021, at 3:04 PM, Hohensee, Paul <hohensee at amazon.com> wrote:
>>> 
>>> 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.
>> There’s been some effort in GC code to use the Ticks utility (which I think ends up being nanoseconds
>> on all supported platforms) internally, and convert to other types for logging and other API boundaries
>> that require other types.  See, for example,
>> https://bugs.openjdk.java.net/browse/JDK-8208390
>> I thought that had already been done, but apparently not.  Maybe there was just an unfinished prototype?
>> Quite possibly it got too big for one change set.
> 
> This might not be what you were thinking about, but could be interesting to think about anyways.
> 
> At some point I created a prototype to use a chrono-like API to solve the numerous bugs we've had when accidentally mixing seconds and milliseconds. See:

Yes, I remember this.  I liked the idea, but at the time we didn’t have C++11/14 available.  Now we do.

> https://www.cplusplus.com/reference/chrono/
> https://cr.openjdk.java.net/~stefank/prototype/durations/
> 
> That in itself was good enough to find conversion bugs. On top of this I started to convert the G1 code to use "duration" (backed by nanos), and only convert to seconds and milliseconds at the boundaries. I don't have that patch anymore, but from internal mails I see that these were my thoughts at that point:
> 
> "I ... didn't like that because G1 pervasively uses doubles and does a lot of statistics on these double values, so using Duration<> forces me to uses duration_casts in many places in G1 (to allow lossy conversions). I'll reimplement that part so that I can show that part more clearly and so that we can discuss if there are better ways around those problems. "

The current use of Ticks has essentially the same problem.  Except we're
writing out the conversions all over the place, rather than having them
nicely packaged up. I find that frequently irritating, but nobody (including
me) has gotten so irritated as to do something about it.

> Priorities changed and we're now at C++14. Would it make sense to investigate using chrono?

Unless and until we address the issue of JFR using the so-called
fast-unordered clock (JDK-8211240, which is confidential for annoying
reasons and needs to be resubmitted in the open. Summary is "Systematic
investigation regarding latency for os::elapsed_counter() vs rdtsc()".), we
need to use the paired form of Ticks.  But I think the underlying
implementation of Ticks could use std::chrono.

We may (probably) want to use our own clock sources rather than whatever the
C++ standard library provides us, in order to be sure we're consistent with
other code, including Java. I don't remember how hard it is to define a
clock source, though I'm guessing it's not hard.