[8u-dev] RFR (S): JDK-8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call
david.holmes at oracle.com
Mon Apr 22 22:11:18 UTC 2019
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/
Why does this need to be pushed to the VM? Why not do the
pre-loading/initializing at the Java level?
> 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.
More information about the core-libs-dev