[8u-dev] RFR (S): JDK-8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call
sci at amazon.com
Tue Apr 23 14:44:52 UTC 2019
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.
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.
More information about the core-libs-dev