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.hol...@oracle.com> wrote on 22/10/2019 14:12:55:
From: David Holmes <david.hol...@oracle.com>
To: Adam Farley8 <adam.far...@uk.ibm.com>, Java Core Libs <core-
libs-...@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
