RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()
David Holmes
david.holmes at oracle.com
Mon Apr 27 12:21:27 UTC 2015
On 27/04/2015 5:28 PM, Daniel Fuchs wrote:
> Hi David,
>
> On 4/27/15 3:21 AM, David Holmes wrote:
>> 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?
>
> The initialization will not happen before the first class calls
> Logger.getLogger() or LogManager.getLogManager().
> In particular, it does not happen when the LogManager.class is loaded
> (that is: it no longer happens as part of the class static
> initialization).
>
> I see Alan replied to that question as well...
I'm just wondering what anyone might be running with a customized core
class that uses logging, and which may now fail due to the different
requirements.
>> 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).
>
> Exactly. Thanks!
>
>> But why are these initialized to true and not false ??
>> 184 private volatile boolean initializeGlobalHandlersCalled = true;
>> 185 private volatile boolean initializeGlobalHandlersDone = true;
>
> It doesn't make sense to try & create global handlers before the
> configuration is read for the first time. In addition the first thing
> that readConfiguration does is to call reset() which switches
> initializeGlobalHandlersCalled to true to avoid that it gets initialized
> before the Properties is later loaded.
>
> I agree that this initialization to 'true' is not intuitive.
> My fingers had been itching several times to change it to false ;-)
> but the 'true' value makes more sense once you look at the
> initialization code path.
>
> I should probably add a comment:
>
> // These variables are initialized to true, to avoid trying
> // to initialize global handlers before the configuration is read
> // for the first time.
Sounds good to me.
Thanks,
David
>
>>
>> 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!
>
> best regards,
>
> -- daniel
>>
>> Thanks,
>> David
>>
>>> comments welcome,
>>>
>>> best regards,
>>>
>>> -- daniel
>
More information about the core-libs-dev
mailing list