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

[Coleen Phillimore]

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

>> I prefer to see this as an extension of UL rather than a stand-alone tracing utility as we have been trying to get rid of the latter and focus on UL. By using UL you also get benefits like easy redirection to a file etc, rather than dumping to tty.
>> 
>> But I understand about the "noise" aspect. Need to think more on this ...
>
> 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.

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

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