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