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

[Stefan Karlsson]

On 2021-09-03 19:29, Kim Barrett wrote:
>> 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.

I had hoped for the opposite. Provide a clock source for Ticks, and use 
std::chrono throughout the JVM (or at least GC).

>
> 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.

In the prototype I set up two clock sources (elapsed time, elapsed 
counter). I think something very similar to that could be plugged into 
std::chrono.

I tried to prototype a Ticks clock source, but hit problems with trying 
to convert durations based on Ticks to other types of durations:
https://gist.github.com/stefank/e7128e72e3fd120384444337e96f21cc

Maybe I'm missing something, or maybe chrono isn't easily adapted to use 
a non-primitive time representation, I'm not sure. This might point in 
the direction you mentioned, to instead use chrono inside Ticks. I'm not 
sure how much that would help the GC code. We would still have a mix 
usage of two different time APIs.

StefanK