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.
