RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Mandy Chung mandy.chung at oracle.com
Thu May 12 20:43:27 UTC 2016


> On May 11, 2016, at 8:39 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> While good progress was made during the original code review, all of the
>> overridden methods in Properties caused an explosion of unnecessary
>> JavaDoc (see specdiff at [2]).  With the recent fix of 8073100 (new
>> "@hidden" JavaDoc tag), we can now avoid the additional clutter.
> 
> The existing javadoc has a section "Methods inherited from java.util.Hashtable" which I can't see in your specdiff - what does that section say about the methods you overrode to delegate to the CHM instance? Are they simply not listed, or does it lie and claim they are inherited, or does it have some new way to present "@hidden" things?

No javadoc will be generated for @Hidden methods.  Kumar can give more details about it.

> 
>> FWIW, the deadlock code path is now different than what is seen in the
>> bug report (see [3]).  We're now getting hung up on the
>> Integer.getInteger() call to get MAX_ARITY on line 60 of
>> MethodHandleImpl [4].
> 
> So while the original deadlock is resolved by all this change, there still exists a deadlock.

Properties::get is now lock-free with this change.  The stack trace below is the deadlock before this fix.

> I can see from the details that store() locks the properties object and can lead to MethodHandleNatives.linkCallsite, while in another thread we have
> 
> at java.util.Hashtable.get(java.base at 9-ea/Hashtable.java:370)
> 	- waiting to lock <0x00000006cff097f0> (a java.util.Properties)
> ...
> at java.lang.invoke.CallSite.<clinit>(java.base at 9-ea/CallSite.java:230)
> 	at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base at 9-ea/MethodHandleNatives.java:250)
> 
> I think we have some fundamental initialization order problems that need to be addressed in a holistic way rather than deadlock by deadlock (or initialization failure by initialization failure).

The startup initialization has been updated significantly.  That should clean up a few initialization failures.  However, I agree that there are still deadlocks and initialization failures to be addressed.

Mandy




More information about the core-libs-dev mailing list