RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

[Daniel Fuchs]

On 13/01/2020 10:28, Seán Coffey wrote:
> some off line comments suggested that I could move the jar 
> initialization checks to the EventHelper class. With that in place, the 
> EventHelper utility class should never initialize the logging framework 
> early during jar initialization.
> 
> http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webrev/

Looks good to me Seán. Probably safer than the other alternatives.
   46     private static boolean loggingSecurity;
that should be volatile too.


best regard,

-- daniel

> 
> regards,
> Sean.
> 
> On 16/12/2019 14:15, Seán Coffey wrote:
>> The recent crypto event logging mechanism (JDK-8148188) has introduced 
>> a regression whereby the System Logger may be invoked too early in the 
>> bootstrap phase. This causes issue when JarFile objects are locked by 
>> JarFile verifier initialization code. The logging work records an X509 
>> Certificate which is used during the jar file 
>> verification/initialization phase and hence leads to an early 
>> System.Logger call.
>>
>> One thread invokes the initialization of the Logger framework via 
>> ServiceLoader and waits to lock a JarFile in use via another thread. 
>> Unfortunately that other thread is also waiting for the System Logger 
>> to initialize. For now, I think we can avoid the early Logger 
>> initialization via use of a ThreadLocal. I've tried reproducing the 
>> reported issue through manual and automated tests but to no avail. 
>> I've added a new ServiceLoader test which has concurrent threads. One 
>> is loading providers and another is initializing JarFile verifiers. 
>> Hope it helps improve code coverage for the future.
>>
>> JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/
>>