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

[Coleen Phillimore]

On Thu, 22 Jun 2023 01:12:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I assume you mean make the feature require `-Xlog:class+load` in addition? I had that at first but it adds a lot of noise when one is only interested in certain classes as it now shows a UL line for every class loaded, including those not matched by the filter.
>> I think this is such niche functionality, it's better to keep it separate from `-Xlog:class+load`.
>
> 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.

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

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