On Thu, 11 May 2023 18:34:45 GMT, Daniel Fuchs 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.m
On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs 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.mi
> 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
On Thu, 11 May 2023 10:24:34 GMT, Jaikiran Pai wrote:
>> Ah - I see that `PrintStream` lock can be accessed through SharedSecrets...
>> Hmmm. OK - then maybe I should leave InternalLock alone and just use
>> ReentrantLock. Let me prototype that.
>
>> Ah - I see that PrintStream lock can be acce
On Thu, 11 May 2023 10:15:49 GMT, Daniel Fuchs wrote:
> Ah - I see that PrintStream lock can be accessed through SharedSecrets
I think Alan was talking about the
protected Object lock
on `java.io.Reader` and `java.io.Writer` classes which can be manipulated by
their sub-classes and that's wh
On Thu, 11 May 2023 10:13:04 GMT, Daniel Fuchs wrote:
>>> It's the same reason here: in these classes (and before that change) the
>>> lock is `this` which is always exposed to subclasses or external classes.
>>> If a handler uses `InternalLock`, and an external class
>>> `synchronize(handler)
On Thu, 11 May 2023 08:51:45 GMT, Alan Bateman wrote:
>> I can revert to using plain `ReentrantLock` if you think it's preferable.
>
>> It's the same reason here: in these classes (and before that change) the
>> lock is `this` which is always exposed to subclasses or external classes. If
>> a h
On Thu, 11 May 2023 07:52:51 GMT, Daniel Fuchs wrote:
>> It's the same reason here: in these classes (and before that change) the
>> lock is `this` which is always exposed to subclasses or external classes. If
>> a handler uses `InternalLock`, and an external class `synchronize(handler)`
>> th
On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs 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.mi
On Thu, 11 May 2023 07:28:03 GMT, Alan Bateman wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use locks consistently
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 88:
>
>> 86:
On Thu, 11 May 2023 07:51:12 GMT, Daniel Fuchs wrote:
>> src/java.logging/share/classes/java/util/logging/Handler.java line 88:
>>
>>> 86: return null;
>>> 87: } else {
>>> 88: return InternalLock.newLockOrNull();
>>
>> I'm surprised to see InternalLock used here
On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs 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.mi
On Fri, 5 May 2023 13:53:51 GMT, Daniel Fuchs wrote:
> 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
On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs 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.mi
On Fri, 5 May 2023 16:38:13 GMT, Daniel Fuchs 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.mi
> 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
On Fri, 5 May 2023 16:31:18 GMT, Daniel Fuchs wrote:
> Thanks for your observations David!
>
> Use of synchronization in these handler classes has two purposes: one is
> visibility. Since Handlers are used by multiple (logging) threads, and
> potentially configured from different threads (e.g.
> 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
On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs 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.In
On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs 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.In
On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs 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.In
21 matches
Mail list logo
