[8u-dev] RFR (S): JDK-8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call

[David Holmes]

PS. Given you have implemented this in the VM you're asking for a review 
on the wrong mailing list.

David

On 23/04/2019 7:04 am, Sciampacone, Ryan wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8194653
> Webrev: http://cr.openjdk.java.net/~phh/8194653/webrev.00/
> 
> Eliminates a race condition on call to java.nio.file.FileSystems::getDefault() where two threads (one inside a loadLibrary() call) could cause a deadlock if they both referenced this code path.  Priming the code path during startup eliminates the deadlock (<clinit> and loadLibrary0 are single threaded).  Note the JVM is at the end of initialization and the getDefault() call is safe to make.  This does result in a few extra classes being loaded before the user class is touched, but this path was almost inevitably being called once the user class is invoked.
> 
> The general problem of multithreaded class initialization and JNI library loading remains – this patch addresses a defect that is seen out in the field (the defect contains at least 2 public cases, anecdotally I have seen others).
> 
> This is JDK8 only – as discussed in the defect JDK9 and beyond address this problem with a different startup sequence.
> 
> Note that Oracle appears to have picked up this fix (or a version of it) for their 8u repo.
> 
> Paul Hohensee (phh) has agreed to sponsor the fix.
> 
> 
>