> On Apr 1, 2021, at 10:38 PM, Ralph Goers <[email protected]> wrote:
>
> In thinking about this problem I suspect we never noticed that the
> PreciseClock version of our SystemClock class is not garbage free is because
> we previously ran all of our unit tests with Java 8. Now that they are using
> Java 11 that code is being exercised.
>
> I’ve looked at java.time.Clock and java.time.Instant. As far as I know those
> are the only two classes in Java that provide sub-millisecond granularity.
> Unfortunately there is no way to call them to extract the field data we need
> to initialize MutableInstant. I considered modifying our version of
> SystemClock to perform the same actions as java.time’s SystemClock but the
> relevant method there calls jdk.internal.misc.VM.getNanoTimeAdjustment() to
> correct the sub-millisecond portion. That is implemented as a native method
> and seems to only be available to be called by an application when something
> like --add-opens java.base/jdk.internal.misc=xxx is on the command line.
>
> I’ve also considered disabling the PreciseClock when garbage free mode is
> enabled but as far as I can tell we don’t have a single switch for that. So I
> would have to add yet another system property to control it.
One other option is to modify the documentation to indicate timestamps are not
garbage free. But this seems awful since virtually every log event has one. It
would make more sense to use the property to determine which to use so user’s
who wish to be garbage free can continue with millisecond granularity.
Ralph
