RFR: 8193513: add support for printing a stack trace on class loading [v2]
David Holmes
dholmes at openjdk.org
Wed Jun 21 12:52:04 UTC 2023
On Wed, 21 Jun 2023 06:38:21 GMT, Doug Simon <dnsimon at openjdk.org> wrote:
>> src/hotspot/share/oops/instanceKlass.cpp line 3743:
>>
>>> 3741: const ClassFileStream* cfs) const {
>>> 3742: if (TraceClassLoadingCause != nullptr &&
>>> 3743: (strcmp(TraceClassLoadingCause, "*") == 0 || strstr(external_name(), TraceClassLoadingCause) != nullptr))
>>
>> Not sure if "contains" is the right way to match here ??
>>
>> Also I don't see how this matches the example you gave for `Thread` because it only produced a few stacks. ??
>
>> Not sure if "contains" is the right way to match here ??
>
> What else would you suggest? In my experience, I'm typically interested in a specific class or package so substring matching has been sufficient. I don't think this feature warrants the complexity of regular expression matching.
>
>> Also I don't see how this matches the example you gave for Thread because it only produced a few stacks. ??
>
> Are you commenting on the fact that the first few classes in my example have no stacks? That's because that loading happens in the VM before any Java code is running. Also note that my example does not contain the complete execution trace (as indicated by the `...` at the end).
Ah I see, so those initial entries are empty stacks because you are only showing Java frames. I misunderstood. I was thinking a full native trace. If a class is loaded as part of verification of another class, the Java stack might not be that useful.
As for "contains" ... just not sure if it it might not match too many things ... I guess you just have to be more specific about whether you specify a simple class name of FQN.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14553#discussion_r1236948778
More information about the hotspot-dev
mailing list