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
