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

[Stefan Karlsson]

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:

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

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

StefanK

>
>