RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()

[David Holmes]

On 28/04/2015 6:13 PM, Daniel Fuchs wrote:
> On 28/04/15 09:59, Peter Levart wrote:
>> On 04/27/2015 10:05 PM, David Holmes wrote:
>>>>>>> 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.
>>>
>>> But then I just recalled that we used to use ReentrantLock via
>>> ConcurrentHashMap in Class, so introducing it early is not likely to
>>> cause any issue.
>>>
>>> Cheers,
>>> David
>>
>> Hi David, Daniel,
>>
>> CHM in JDK8 is not using ReentrantLock. But in JDK7, it is used, yes.
>>
>> But anyway, is there a special reason to use ReentrantLock here in
>> LogManager instead of Java built-in monitor lock? It is reentrant too.
>
> Hi Peter,
>
> That's one of the possibility I was envisaging - but I didn't feel very
> comfortable with synchronizing the whole method bodies.

You don't need to. The scoping of a sync block can be the same as that 
of a ReentrantLock, and you can use an internal private lock object.

But I don't have any concerns with using ReentrantLock.

David
-----

> Using a reentrant lock also offers more possibility for evolutions
> like try locking or timeout locking - which you can't do with a
> monitor (unless you reinvent ReentrantLock)...
>
> best regards,
>
> -- daniel
>>
>> Regards, Peter
>>
>