Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.14.1
-
None
-
None
Description
(from the mailing list)
Ralph:
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.
Remko
My understanding is that PreciseClock is garbage-free because the JVM does escape analysis.
(...)
I think I tested this on Java 9, and the Google java-allocation-instrumenter library could not detect allocations.
Ralph
That isn’t the case when I ran it with Java 11 and the latest version of the allocation tool. Virtually everything failed since almost everything creates a timestamp.