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

[Sciampacone, Ryan]

Hey David, the bug was marked as core-libs and so this is why I posted to core-libs-dev.  I'm happy to move the conversation elsewhere.  Should I move this to hotspot-runtime-dev or do you have another suggestion?

On 4/22/19, 3:13 PM, "David Holmes" <david.holmes at oracle.com> wrote:

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