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

[Seán Coffey]

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/

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/
>