RFR: 8193513: add support for printing a stack trace on class loading [v7]
Ioi Lam
iklam at openjdk.org
Fri Jul 7 19:30:00 UTC 2023
On Fri, 7 Jul 2023 17:54:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:
> > We should organize the logging so that they are grouped logically.
>
> There's nothing ungrouped about the original order; the order of `class+load` and `class+load+cause` were swapped but they were still grouped together.
My point is if you want to see both the stack and the loader for a class, now you can see them right next to each other in the log file, without having to scroll through pages of call stacks.
The new version looks good to me.
> > This happens before the class is actually loaded, so those logs cannot appear after the main class+load tag.
>
> Maybe I'm interpreting the output incorrectly, but that's not what I see:
>
> ```
> > java "-Xlog:class+load=debug,class+load+cause=info,class+load+placeholders=debug" -XX:LogClassLoadingCauseFor=java.lang.StringCoding --version
> ...
> [1.917s][debug][class,load,placeholders] entry java/lang/StringCoding : find_and_add LOAD_INSTANCE
> [1.917s][debug][class,load,placeholders] loadInstanceThreadQ threads:0x000000013080a000,
> [1.917s][debug][class,load,placeholders] superThreadQ threads:
> [1.917s][debug][class,load,placeholders] defineThreadQ threads:
> [1.917s][info ][class,load ] java.lang.StringCoding source: /Users/dnsimon/dev/jdk-jdk/open/build/macosx-aarch64/jdk/modules/java.base
> [1.917s][debug][class,load ] klass: 0x000000030007acf8 super: 0x0000000300041170 loader: [loader data: 0x00006000034ccaa0 of 'bootstrap'] bytes: 1361 checksum: af8c723a
> [1.917s][info ][class,load,cause ] Java stack when loading java.lang.StringCoding:
Before the class is actually parsed and loaded, its name is first entered into the place holder table. The logging reflects that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14553#discussion_r1256353304
More information about the hotspot-dev
mailing list