search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k stars 721 forks source link

Serviceability Request: Add context class loader to Thread details in javacore.txt #14618

Closed jaridk closed 2 years ago

jaridk commented 2 years ago

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 the CLASSES 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.

pshipton commented 2 years ago

@tajila @keithc-ca fyi

keithc-ca commented 2 years ago

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?

pshipton commented 2 years ago

The first option seems easier to read, but I don't have a strong preference.

jaridk commented 2 years ago

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.

keithc-ca commented 2 years ago

Ok, we'll go with the first format ~(although I may adjust the tag 3XMJAVALTHRCCL)~.

pshipton commented 2 years ago

@jaridk what JVM are you looking for this in?

jaridk commented 2 years ago

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.