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

[Martin Buchholz]

On Tue, Oct 22, 2019 at 3:58 PM David Holmes <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)
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 .

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.