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.hol...@oracle.com> wrote:
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.
>
>
>
