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

[Doug Simon]

On Fri, 7 Jul 2023 15:51:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Not sure what you mean. The `class+load+cause` log output includes the name before the stack. See the updated examples in this PR's description.
>> 
>> If you mean `class+load+cause` log output precedes `class+load` log output, then yes, that is the case and it's intentional to keep these logging features independent of each other as David suggested (https://github.com/openjdk/jdk/pull/14553#discussion_r1249847278). Since they are independent, it should not matter which output comes first.
>
> Even if they are independent, relevant output should be grouped together. Currently, if we specify `-Xlog:class+load*=debug`, the output would look like this:
> 
> 
> Java stack when loading  java.util.concurrent.ConcurrentHashMap$ValuesView
> ...
> [many many lines of output]
> ...
> java.util.concurrent.ConcurrentHashMap$ValuesView source: shared objects file
>   klass: 0x000000080033a0f8 super: 0x000000080033a320 loader: [loader data: 0x00007faa34113890 of 'bootstrap']
> 
> This makes it difficult to see all the information of this class at a glance.

If I'm interested in class load cause logging of `java.util.concurrent.ConcurrentHashMap$ValuesView`, I don't particularly care about the `class+load` output for that class.
Note that some of the `class+load+placeholders` output is going to be shown after `class+load+cause` anyway.
That said, I've pushed a commit to implement your request: d84186840b874ba74e270f6ac51cc0ed71d655f5

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14553#discussion_r1256098870