RFR: 8193513: add support for printing a stack trace on class loading [v4]

[David Holmes]

On Sun, 2 Jul 2023 21:51:59 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> In the development of libgraal, it has been very useful to see why a given class is loaded (e.g., trying to reduce startup time by avoiding unnecessary eager class loading). One way to do this is to see the stack trace when the VM loads a class. The only possibility currently is to add a static initializer to the class of interest. However, not only is this not always possible but it doesn't correlate with class loading but with class initialization.
>> 
>> This PR proposes a `TraceClassLoadingCause` VM flag:
>> 
>> 
>>   product(ccstr, TraceClassLoadingCause, nullptr, DIAGNOSTIC,               \
>>           "Print a stack trace when loading a class whose fully"            \
>>           "qualified name contains this string ("*" matches "             \
>>           "any class).")                                                    \
>> 
>> 
>> I would have liked to implement this using Unified Logging but UL has no support for filtering on the class names.
>> 
>> Example usage:
>> 
>> java -XX:+UnlockDiagnosticVMOptions -XX:TraceClassLoadingCause=Thread --version
>> Loading java.lang.Thread
>> Loading java.lang.Thread$FieldHolder
>> Loading java.lang.Thread$Constants
>> Loading java.lang.Thread$UncaughtExceptionHandler
>> Loading java.lang.ThreadGroup
>> Loading java.lang.BaseVirtualThread
>> Loading java.lang.VirtualThread
>> Loading java.lang.ThreadBuilders$BoundVirtualThread
>> Loading java.lang.Thread$State
>> 	at jdk.internal.misc.VM.toThreadState(java.base/VM.java:336)
>> 	at java.lang.Thread.threadState(java.base/Thread.java:2731)
>> 	at java.lang.Thread.isTerminated(java.base/Thread.java:2738)
>> 	at java.lang.Thread.getThreadGroup(java.base/Thread.java:1957)
>> 	at java.lang.ref.Reference$1.startThreads(java.base/Reference.java:314)
>> 	at java.lang.System.initPhase1(java.base/System.java:2206)
>> Loading java.lang.Thread$ThreadIdentifiers
>> 	at java.lang.Thread.<init>(java.base/Thread.java:734)
>> 	at java.lang.Thread.<init>(java.base/Thread.java:1477)
>> 	at java.lang.ref.Reference$ReferenceHandler.<init>(java.base/Reference.java:198)
>> 	at java.lang.ref.Reference.startReferenceHandlerThread(java.base/Reference.java:300)
>> 	at java.lang.ref.Reference$1.startThreads(java.base/Reference.java:318)
>> 	at java.lang.System.initPhase1(java.base/System.java:2206)
>> Loading java.lang.ref.Finalizer$FinalizerThread
>> 	at java.lang.ref.Finalizer.startFinalizerThread(java.base/Finalizer.java:187)
>> 	at java.lang.ref.Reference$1.startThreads(java.base/Reference.java:319)
>> 	at java.lang.Sy...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add class+load+cause and make its output independent of class+load

One nit but otherwise I think this looks okay. Isolating from class+load seems reasonable. Thanks for the sample output.

src/hotspot/share/oops/instanceKlass.cpp line 3839:

> 3837:   if (log_cause_native || log_is_enabled(Info, class, load, cause)) {
> 3838:     JavaThread* current = JavaThread::current();
> 3839:     ResourceMark rm;

Nit: use `ResourceMark rm(current);` please

src/hotspot/share/oops/instanceKlass.cpp line 3869:

> 3867:       info_stream.print_cr("Native stack when loading %s:", name);
> 3868: 
> 3869:       // Print each native stack line to the log

`LogStream`  extends `OutputStream` which has some support for indentation. I thought there should be a way to simplify this, but given you have to break into lines anyway the `\t` seems easier than using any of the built-in indentation functionality.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14553#pullrequestreview-1510357762
PR Review Comment: https://git.openjdk.org/jdk/pull/14553#discussion_r1250228466
PR Review Comment: https://git.openjdk.org/jdk/pull/14553#discussion_r1250316925