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

[Peter Levart]

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.

Regards, Peter