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