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

[David Holmes]

Hi Martin,

This is going a bit OT I think ...

On 24/10/2019 1:24 pm, Martin Buchholz wrote:
> 
> 
> On Tue, Oct 22, 2019 at 3:58 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
> 
>     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).
> 
> 
> I had a need to debug an error in a <clinit> this week and was again 
> frustrated by the difficulty.
> Classes falling into Erroneous state are rare so it seems reasonable to 
> save the exception as a cause for the subsequent NCDFE (probably can't 
> fix the misleading name of the exception)

So as you know such a request existed:

https://bugs.openjdk.java.net/browse/JDK-8048190

and was closed as it was considered that TraceExceptions (now 
-Xlog:exceptions) would provide the additional information. As noted in 
that bug there are also semantic issues about recording the cause of an 
exception in thread B, with an exception object that was thrown in 
thread A. So unless someone comes up with a very convincing argument, or 
else it prepared to do the work, I don't see that being re-opened.

> I couldn't find a way to get hotspot to report the stack trace of all 
> exceptions that are thrown; -Xlog:exceptions=trace does not .

-Xlog:exceptions shows where the exception is thrown and how it proceeds 
up the stack. It doesn't print the full stacktrace. That seems like a 
logging request for the Throwable constructor, or fillInStackTrace, to 
me, rather than trying to have the VM do it. IIRC we store minimal VM 
information in the backTrace which is expanded when needed into the full 
StacktraceElements array.
> I was also frustrated that a StackOverflowError failed to report the 
> name of the thread and the stack size that was exceeded.  But 
> -Xlog:threads*=trace helped there.

The issue there is that SOE instances are allocated natively without 
executing any Java code (as we have run out of the Java stack) so we 
can't (easily) create a String message for the exception. However 
-Xlog:exceptions could be expanded to report that information at the 
point we throw the SOE. I filed - JDK-8232923.

Cheers,
David