RFR: 8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call

[Andrew John Hughes]

On 20/06/2019 18:08, Andrew John Hughes wrote:
> On 19/06/2019 11:02, Andrew Dinn wrote:
>> Could I please have reviews for the following patch against jdk8u-dev:
>>
>>   Webrev: http://cr.openjdk.java.net/~adinn/8194653/webrev.00/
>>   JIRA:   https://bugs.openjdk.java.net/browse/JDK-8194653
>>
>> Background:
>>
>> The email threads discussing this issue were a tad inconclusive for both
>> jdk8u and jdk9+.
>>
>> On jdk8 a suggestion was left hanging that a fix in the jdk not jvm
>> might be better.
>>
>> On jdk9+ upwards the deadlock does not manifest but it might do in
>> future so an investigation was requested by Alan Bateman which has not
>> been followed up.
>>
>> Nevertheless, Oracle have applied a jdk8u patch in 8u212, although using
>> a different JIRA issue.
>>
>>   https://bugs.openjdk.java.net/browse/JDK-8222858
>>
>> I am not sure why this has been done as a backport? Note it may be
>> relevant that the original JIRA (8194653) is marked as being against 8u231.
>>
>> Testing:
>>
>> The reproduced supplied with the original patch and included in the
>> above webrev fails before applying and works afterwards.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>
> 
> The clue is in the build number. The high (30+) build numbers generally
> indicate customer builds, as far as we can tell. It's relatively common
> for an issue to be listed as fixed in 8ux b30 and 8ux+1 b30, before
> finally being in the GA build of 8ux+2. I think this one just looks
> extra odd because the main bug is fixed directly in 8, rather than a
> later JDK release and all the 8 fixes being backports. Our filter
> actually missed some bugs marked as 8u202 b3x last cycle, because it was
> assumed they were fixed by the integration of 8u202, before Oracle quit
> the project, when actually that work only went up to b08, the GA release.
> 
> This one is another example:
> 
> https://bugs.openjdk.java.net/browse/JDK-8155951
> 
> That given, I think we can include this in the October CPU, rather than
> trying to rush in a release for July's, which freezes next week.
> 
> Thanks,
> 

Is there any movement on this? We're now looking at rampdown for 8u232,
and I see no further agreement towards a fix for this.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew