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

[David Holmes]

Hi Brent,

On 13/05/2016 7:02 AM, Brent Christian wrote:
> Hi, David
>
> On 5/11/16 8:39 PM, David Holmes wrote:
>> On 11/05/2016 7:56 AM, Brent Christian 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?
>
> Good catch!  specdiff didn't pick up that change with --config=javadoc,
> which is a bit troubling, but it does show up with --config=plain:
>
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/specdiff-plain/Properties.html
>
>
> With all of the inherited methods @hidden, it looks like that section
> is left out altogether.

Okay, so I have to say @hidden seems to me to be seriously flawed! If a 
class has a method that can be called then IMHO that has to be 
documented in that class as either being first defined, overridden, or 
inherited - it can't just say nothing as-if the method were not there!

If we are overriding in a trivial way that does not change the 
specification at all then there should be a simple way to show that - 
perhaps the "Methods inherited from ..." should be split into two parts: 
method implementations inherited from ..., and method specifications 
inherited from ... ??

I guess I need to raise this with the javadoc folk :( Is there a mailing 
list for that?

>> while the original deadlock is resolved by all this change, there
>> still exists a deadlock.
>
> I should have been clearer.  Since this issue was filed, the code paths
> in question changed a fair bit with jigsaw.  Pre-fix, the test still
> hung, but in different code (NewDeadlock.txt).  As Mandy said, with the
> fix, Properties::get no longer locks on the object, and this test passes.

Ah, sorry about the misunderstanding.

Thanks,
David

> Thanks,
> -Brent