I don’t have an account in the bug tracking system. Could someone possibly update the issue noted below to indicate that Apache Log4j 2 would also like that enhancement?
Thanks, Ralph > On Apr 5, 2021, at 1:26 PM, Roger Riggs <roger.ri...@oracle.com> wrote: > > Hi, > > Java does not have a data type with enough resolution to hold a full > nanosecond value. > Hence the implementation of Instant holding seconds and nanos. > > There is an long dormant enhancement request to return micro-seconds as a > long. > 8196003 <https://bugs.openjdk.java.net/browse/JDK-8196003> java.time Instant > and Duration methods for microseconds > > That might be useful if the application gets enough resolution from > microseconds. > There might be some clever interpolation between System.currentTimeMillis() > and adjusting with System.nanoTime(). > Though it would likely not be exactly synchronized with the values from > Instant. > > Regards, Roger > > > On 4/5/21 3:56 PM, Brian Goetz wrote: >> Project Valhalla will allow Instant to be migrated to a primitive class, >> which would address your problem. >> >> On 4/2/2021 7:47 PM, Ralph Goers wrote: >>> Log4j 2 supports the notion of a PreciseClock - one that can be initialized >>> to something more precise than a millisecond. At the same time it also >>> supports running with no heap allocations in certain circumstances. I am in >>> the process of moving our master branch to require Java 11 as the minimum. >>> In doing so I am encountering unit test errors while verifying that logging >>> is garbage free. They all occur allocating an Instant. >>> >>> The code we have simply does >>> >>> public void init(MutableInstant mutableInstant) { >>> Instant instant = java.time.Clock.systemUTC().instant(); >>> mutableInstant.initFromEpochSecond(instant.getEpochSecond(), >>> instant.getNano()); >>> } >>> In our previous tests we had thought the allocation was being eliminated >>> due to escape analysis since the data is being extracted from the Instant >>> and not passed along. However, after upgrading the Google test library and >>> the JDK version it appears that is not the case. >>> Ideally we would really like something like >>> >>> public void init(MutableInstant mutableInstant) { >>> java.time.Clock.systemUTC().initInstant(mutableInstant); >>> } >>> >>> where Mutable instant would implement an interface that has the two set >>> methods.The method would execute the same logic that is in the instant() >>> method but instead of creating a new Instant it would call the set methods >>> for the provided object. >>> >>> This would allow us to either have the MutableInstants in ThreadLocals or >>> some other mechanism to ensure they are thread safe and have no heap >>> allocations. As it stands now I see no way to gain access to the higher >>> precision clock without memory allocation. >>> >>> Do you know of another way to do this? Am I missing something? >>> >>> Ralph >> > >
