On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> Several Handlers class use monitors to synchronize when formatting / >> publishing LogRecords. >> When logging within a VirtualThread, holding this monitor can cause the >> carrier thread to be pinned. >> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some >> java.io classes (such as PrintStream) to avoid pinning the carrier thread. > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Use locks consistently > > Something I was wondering: > > > Use of InternalLock can be disabled with -Djdk.io.useMonitors=true > > > But should we have a property to force the use of InternalLock (when > > enabled) even in the presence of custom handlers subclasses? We could use > > -Djdk.io.useMonitors=false to mean that - or introduce a new system > > property specific to java.util.logging.Handlers. > > If at all we want to always use an `InternalLock` irrespective of the > `-Djdk.io.useMonitors` system property, then perhaps a simpler way might be > to introduce new > > ```java > public static InternalLock newLock() > ``` > > method in `InternalLock` class, which then doesn't check the system property > and instead will always return a new lock. That way we wouldn't have to > introduce any new system property. That would also mean that we don't expose > this control to the application/user, which I think would be a good thing > since it's my opinion that this is a bit too complex detail to be configured > by the applicaiton. My concern was the opposite: do we need a property to force usage of `j.u.c.Lock` (and disable use of synchronized) even if the handler is subclassed by a custom subclass outside of the JDK? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1543514267
