RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()
David Holmes
david.holmes at oracle.com
Mon Apr 27 01:21:15 UTC 2015
Hi Daniel,
On 25/04/2015 3:07 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch that tries to improve the locking
> strategy in LogManager.
>
> The patch proposes to use a Reantrant lock to deal with
> configurations changes in reset() and readConfiguration(),
> and avoids lock contention in initializeGlobalHandlers()
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8077846/webrev.00/
How early in VM startup can logging be initialized and used? I just
wonder whether the use of ReentrantLock changes that at all?
Took me a while to understand the use of initializeGlobalHandlersDone. I
think this comment:
1622 // If we are in the process of initializing global handlers we
1623 // also need to lock & wait (this case is indicated by
1624 // initializeGlobalHandlersDone == false).
would be a little clearer as:
1622 // If we are in the process of initializing global handlers we
1623 // also need to acquire the lock to wait until it is complete
1624 // (this case is indicated by initializeGlobalHandlersDone
== false).
But why are these initialized to true and not false ??
184 private volatile boolean initializeGlobalHandlersCalled = true;
185 private volatile boolean initializeGlobalHandlersDone = true;
I think this code/comment:
1629 if (initializeGlobalHandlersCalled) return; //
recursive call
would also be clearer as:
1629 if (initializeGlobalHandlersCalled)
return; // recursive call or another thread did it
already
Thanks,
David
> comments welcome,
>
> best regards,
>
> -- daniel
More information about the core-libs-dev
mailing list