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

[Sciampacone, Ryan]

Agreed on the changes since JDK9.

This specific problem doesn't exist in jdk/jdk because even in a (for my example, linux) product image, although FileSystems isn't touched, sun.nio.fs.UnixNativeDispatcher gets initialized as part of startup - this clears up the native library load (nio) collision that could occur through that class.  This is the case we see customers experiencing.  Preloading FileSystems.getDefault() in jdk8 is a mostly inert and friendly (not reaching into the bowels, letting the platform pick the right class) way of getting that problem out of the way.

You can see the corresponding stack traces here that highlight the issue: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html

If the mainline initialization sequence is changed, could this potentially become an issue?  Yes, that's possible - imo given the dependencies it is unlikely.
Would this patch fix this specific issue?  Yes, assuming FileSystem.getDefault() still found its way to the NativeDispatcher which loads "nio".
Would adding this test case detect the issue?  Yes, again assuming the above.

I admit this goes after a fairly specific set of circumstances - but they are the ones that we end up seeing in jdk8.  Fixing the general multi-threaded clinit / loadLibrary paths in the library is likely not worth it given what I believe would be involved.

The jtreg test case in the patch works on jdk/jdk, and also fails in jdk8 until the patch is applied.  All versions after 8 also pass.
 
Does it make sense to open a JBS against the test and have it applied / backported?

On 4/23/19, 8:31 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:

    On 23/04/2019 15:47, Sciampacone, Ryan wrote:
    >
    > - The problem doesn't exist at jdk9+ because the classes causing this problem get loaded and initialized as part of the initialization sequence "naturally" (ie: I see no indication that they are loaded to solve this specific problem).  I agree that jdk8 is unlikely to have dramatic changes in initialization moving forward, but putting it as part of (to me) the more streamlined create_vm() function made sense from a "safety" perspective as it felt more controlled and unlikely to be perturbed by any other change in the initialization code flow (class library or vm).
    >
    True for JDK 9 but there has been significant changes since than and the 
    file system is not eagerly loaded since JDK 10 or 11. So I think it 
    needs further investigation to see if we have a potential issue in the 
    main line or not.
    
    -Alan