-
Enhancement
-
Resolution: Fixed
-
P4
-
13
-
b06
Quite often it's useful to see why a given class is loaded (e.g., trying to reduce startup time for an app by avoiding unnecessary eager class loading). One way to do this is to see a 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.
In the graal-jvmci-8 fork, we added a -XX:+TraceClassLoadingStack option[1] to support this.
[~alanb] makes a good point that If something like this is added then it could be useful to specify a pattern or even a list of class names to avoid a stack trace for every class. That might help with interference too when there is a lot of class loading going on in different threads.
Update: See https://git.openjdk.org/jdk/pull/14553 for details on how this was implemented as an -Xlog option.
[1] https://github.com/graalvm/graal-jvmci-8/commit/25de3259d10b8606e318ceecbdf0195d3b1f196f
In the graal-jvmci-8 fork, we added a -XX:+TraceClassLoadingStack option[1] to support this.
[~alanb] makes a good point that If something like this is added then it could be useful to specify a pattern or even a list of class names to avoid a stack trace for every class. That might help with interference too when there is a lot of class loading going on in different threads.
Update: See https://git.openjdk.org/jdk/pull/14553 for details on how this was implemented as an -Xlog option.
[1] https://github.com/graalvm/graal-jvmci-8/commit/25de3259d10b8606e318ceecbdf0195d3b1f196f
- relates to
-
JDK-8311542 Consolidate the native stack printing code
- Open
-
JDK-8328639 Add support for including a native stack trace in -Xlog:exceptions
- Open
-
JDK-8311788 ClassLoadUnloadTest fails on AIX after JDK-8193513
- Resolved