Closed jaridk closed 2 years ago
@tajila @keithc-ca fyi
This is relatively straight-forward to do. I'd like opinions on how to present the information.
My first version adds the 3XMJAVALTHRCCL
line:
3XMTHREADINFO "main" J9VMThread:0x0000000000016F00, omrthread_t:0x00007F17180079A0, java/lang/Thread:0x00000000FFF04F70, state:R, prio=5
3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false)
3XMJAVALTHRCCL jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFF133A8)
3XMTHREADINFO1 (native thread ID:0x7DCD, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00001020)
Alternatively, the new information can be added to the 3XMJAVALTHREAD
line:
3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false, contextClassLoader:jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFF133A8))
Preferences anyone?
The first option seems easier to read, but I don't have a strong preference.
I agree with Peter on both counts. The (small) disadvantage of the second approach is that depending on how you're reading it and what the value is, you might have to scroll right a bit to read the whole thing.
Ok, we'll go with the first format ~(although I may adjust the tag 3XMJAVALTHRCCL
)~.
@jaridk what JVM are you looking for this in?
I'm a WebSphere Application Server support guy, so IBM/J9 Java 8+ would be ideal. No time/fixpack requests, although the fact that it looks like it's already scheduled to show up in a refresh is surpassing my wildest expectations on that front already.
This issue is a serviceability request, that a thread's context class loader (the
Thread.contextClassLoader
field) be included in the summary of thread information in the Thread Details section of a javacore. In some support scenarios, it's useful to know the context class loader of a thread at the time an issue occurs, but under current circumstances that information is only available by either modifying the Java application to explicitly print that value or by inspecting a full system core. As javacores are much leaner and more accessible than system cores (not to mention much more reliably created and collected), particularly for issues around thread behavior, this would be a quicker way to get at that information without having to rely on the application - in support scenarios, an application may not be modifiable by the person working with the support agent.The information wouldn't need to be terribly detailed - the class loader type and address, as in the
CLTEXTCLLOADER
entries later in the javacore, would be perfectly sufficient (any additional details can come from finding that object in theCLASSES
section of the javacore). There is already some detail on threads' attributes in the Thread Details section (daemon status, native ID, etc.), so my thought is that this could be included along with that information.Feel free to let me know if you have any additional thoughts or questions for me regarding this request.