Hi Mikhail,
It seems the problem is not limited to EventQueue only. Even if you solve it for EventQueue, the
EventQueue ctor may cause a chain of calls where some other AWT class is first accessed and
initialized. What if it contains the same getLogger() call in a static block?
If you agree with this, then there should be a generic solution for the
deadlock.
What comes to my mind is the following. The deadlock happens due to a reverse lock taking order. Can
we change it?
In LogManager.getUserContext() it seems like the javaAwtAccess lock scope can be narrowed down.
Namely, we can move the javaAwtAccess.getAppletContext() line out of it. In which case the method
implementation should be additionally synchronized. For instance, we can use the getAppContextLock
for the whole body of the method. Is the method implemented somewhere else except the AppContext class?
Will it work from your point of view? (Probably, I didn't take into account all
the details.)
Regards,
Anton.
On 16.01.2015 17:18, mikhail cherkasov wrote:
Hi all,
JBS: https://bugs.openjdk.java.net/browse/JDK-8065709
Webrev: http://cr.openjdk.java.net/~mcherkas/8065709/webrev.00/
AppContext creation is guarder by getAppContextLockand, but during AppContext
creation
we also call EventQueue initialization, during EQ initialization logger
initialization happens
it acquires "javaAwtAccess". if "javaAwtAccess" is acquired by other it can
lead to deadlock:
T1 T2
start AppContext creation
acquire javaAwtAccess
acquire getAppContextLock
init EQ call getAppContext
init Logger waiting for getAppContextLock
waiting for javaAwtAccess
I applied the fix suggested in jbs comments by Petr.
I replaced eager logger initialization in EQ with lazy, so we won't invoke
Logger
during EQ initialization as result no deadlock.
Thanks,
Mikhail.
