RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

[David Holmes]

On 23/10/2019 2:10 am, Ioi Lam wrote:
> Hi Adam,
> 
> The HotSpot logging option:
> 
>        -Xlog:class+load=debug
> 
> will show the class loader, super class, interfaces, size of the 
> classfile, etc.
> 
> A related option:
> 
>        -Xlog:class+resolve=debug
> 
> shows all the class resolution done by the Java code during execution.
> 
> You're right that these logs happen only when the class is successfully 
> loaded/resolved. If we add similar logs for failures, will that address 
> your needs? The syntax would be something like
> 
>        -Xlog:class+load+failure=debug

Not sure that is meaningful as it isn't an error for a particular loader 
to not find a class, it's only an error for the entire loading process 
to fail to find it and that's already reported by the 
ClassNotFoundException. Any errors with the class after it has been 
found (LinkageErrors etc) should be clearly reported.

I'm not sure anything can really address the "why wasn't my class 
found?" question as the VM can't know where you thought it should be found.

Perhaps one aspect of the class loading/resolution/initialization 
process that can lead to confusion here is that if a class fails to 
execute its static initialization then it is marked as Erroneous and all 
subsequent attempts to use that class result in NoClassDefFoundError 
being thrown. If the original ExceptionInInitializerError got swallowed 
somewhere then that can cause great confusion as to why the later NCDFE 
occurs. The VM logging should help in that case - though I'd have to 
confirm that (if it doesn't that should be fixed).

David
-----

> BTW, the bug report mention "What each ClassLoaders' classpath was", but 
> custom class loader doesn't necessarily have the notion of "a class path".
> 
> 
> Thanks.
> - Ioi
> 
> On 10/22/19 8:42 AM, Adam Farley8 wrote:
>> Hi David,
>>
>> I didn't, no. Thanks for pointing it out. :)
>>
>> I see this tells us where the class comes from, much like
>> "-verbose:class".
>>
>> So it's useful when a class can be successfully loaded, but
>> doesn't tell us which classloaders tried to load the class,
>> nor where they looked, etc.
>>
>> Something I could have done a better job conveying was that
>> the core question this debugging is meant to answer is:
>>
>> "Why didn't OpenJDK load the class I wanted it to?"
>>
>> "-Xlog:class+load" seems very useful for finding where a
>> class came from, which answers the "loading the wrong version
>> of a class" problem, but does not seem to give us
>> information in the case of class loading failure.
>>
>> Also, thanks for moving the bug to the correct component. :)
>>
>> Best Regards
>>
>> Adam Farley
>> IBM Runtimes
>>
>>
>> David Holmes <david.holmes at oracle.com> wrote on 22/10/2019 14:12:55:
>>
>>> From: David Holmes <david.holmes at oracle.com>
>>> To: Adam Farley8 <adam.farley at uk.ibm.com>, Java Core Libs <core-
>>> libs-dev at openjdk.java.net>
>>> Date: 22/10/2019 14:14
>>> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output
>>> for Specific Classes
>>>
>>> Hi Adam,
>>>
>>> Did you look at the logging available from the VM: -Xlog:class+load?
>>>
>>> BTW I moved the bug you filed to the correct component.
>>>
>>> Cheers,
>>> David
>>>
>>> On 22/10/2019 8:40 pm, Adam Farley8 wrote:
>>>> Hey All,
>>>>
>>>> This one goes out to anyone who's struggled to figure out
>>>> why OpenJDK isn't loading their class.
>>>>
>>>> The requirement is for OpenJDK to give more detailed
>>>> information while loading user-specified classes (e.g. the
>>>> one OpenJDK is failing to load). Some debug information is
>>>> available while the loading is in-progress, and more is
>>>> available after the fact, but it seems there is not a way
>>>> to monitor what the ClassLoaders are actually doing without
>>>> the use of debugging tools.
>>>>
>>>> For your approval: a formal write-up of the problem (as
>>>> I understand it), and a draft webrev containing the
>>>> proposed solution.
>>>>
>>>> Tests will be developed and added if/when the issue is
>>>> accepted as a problem, and a solution has been selected.
>>>>
>>>> Please review and opine.
>>>>
>>>> Bug: https://urldefense.proofpoint.com/v2/url?
>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwICaQ&c=jf_iaSHvJObTbx- 
>>
>>> siA1ZOg&r=P5m8KWUXJf-
>>>
>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=WEfc_wG4s2o_lhOKcZOykIG0RNybBiMMVbKIzmrlY3k&e= 
>>
>>>> Webrev: https://urldefense.proofpoint.com/v2/url?
>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx- 
>>
>>> siA1ZOg&r=P5m8KWUXJf-
>>>
>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=evj-5Q-0QflLNXj0WL5j9WrCHzNRovUvazY9IH_qNkI&s=jDSMDaCpBBZcYMU- 
>>
>>> IUqDh8PoCyl1Jk1G-QGIPKGjgeY&e=
>>>> Thanks for your time. :)
>>>>
>>>> Best Regards
>>>>
>>>> Adam Farley
>>>> IBM Runtimes
>>>>
>>>>
>>>> Unless stated otherwise above:
>>>> IBM United Kingdom Limited - Registered in England and Wales with
>> number
>>>> 741598.
>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>> 3AU
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU
>>
>