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

[Coleen Phillimore]

On Thu, 29 Jun 2023 01:34:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I agree that this should be integrated with UL because we tried to remove all of the TraceXXX Flags but it would be good to be able to specify a class to log which UL doesn't have the ability to do.
>> If you changed tty->print_raw() to log_info(class, load, stacktrace)("%s", st.as_string()); does it put the decorators on each line?
>> 
>> So one thing you could do is add an option like LogClassLoadingCauseFor=x to match with X.  Then when specified with -Xlog:class+load+cause, that will log the right thing.
>> 
>> The code needs a ResourceMark to use external_name(), and you should put this in a static function just above print_class_load_logging() since it doesn't really do the same thing as the rest of print_class_load_logging() but call it from there.   Then if you want to extend it to print native frames, it would be contained.
>> 
>> Also, this is always JavaThread::current() because all the callers have the current JavaThread.  No need for the null check or the cast.
>
> As David said, the advantage of using logging is for output file redirection and avoidance of more tty in the code.

More.  You could even do -Xlog:class+load+cause+native to get the native stack.  -Xlog:class+load+cause* to get native and Java stacks, and configure it to be compatible with logging rather than these character sequences you have above.

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

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