RFR: 8307535: java.util.logging.Handlers should be more VirtualThread friendly [v3]

[Daniel Fuchs]

On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs <dfuchs at 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