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

[Daniel Fuchs]

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.

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
>