Hi Ryan, 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?
Cheers, David -----
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.
