RFR: 8273239: Standardize Ticks APIs return type

Kim Barrett kim.barrett at oracle.com
Fri Sep 3 17:37:48 UTC 2021


> On Sep 2, 2021, at 5:42 PM, Albert Mingkun Yang <ayang at openjdk.java.net> wrote:
> Here are my two propositions: (more are welcome)
> 
> 1. A consistent return type (`double`) for s/ms/us, but not ns. ns is special because it's the only unit without info loss. Callers expect integral values for s/ms/us can easily discard the fractional part.

I was thinking about suggesting this, but it seemed a little odd.

Also

- There are currently no callers of microseconds().

- Both integral and double milliseconds have real uses.  (Timeouts and such are often integral milliseconds.)

- Many of the current uses of double milliseconds by GC would be better off remaining as unconverted Ticks, with conversions occurring later.

> 2. Keep the existing return-type API, and add two more methods for ms/us returning `double`.
> 
> Note in both propositions, the implementation of `uint64_t nanoseconds()` will be different from `master`, which performs unnecessary double conversion. The new impl should address Kim's concern of `uint64_t-to-double` info loss.

I forgot that there was a conversion through double internally in Ticks.  That would be a good thing to nuke.



More information about the hotspot-dev mailing list