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.29k stars 723 forks source link

Implement Java diagnostic utilities #4655

Open pdbain-ibm opened 5 years ago

pdbain-ibm commented 5 years ago

Implement OpenJ9 equivalents of jps, jstack, jstat, et al.

pdbain-ibm commented 5 years ago

Related issues:

pshipton commented 5 years ago

It may be useful to create check boxes in the initial description for each of the utilities or sub-commands that are planned, and then they can be checked off when done (by changing [ ] to [x]. I've updated the description with an example.

SueChaplain commented 5 years ago

@pshipton Is jinfo in plan please?

doveye commented 5 years ago

I've just read that newer utility jcmd can (should?) be used instead of jstack, jinfo, and jmap.

DanHeidinga commented 5 years ago

This item is about ease of migration - users who are already using jstack / jinfo / jmap / etc will have an easier time migrating if we provide the equivalent commands rather than telling them to first migrate to jcmd.

pdbain-ibm commented 5 years ago

@pshipton @SueChaplain @DanHeidinga I drafted a spec for jstack here: Implement jstack: display runtime state of a Java process #4858 Your comments are welcome.

pdbain-ibm commented 5 years ago

jcmd options:

JFR.stop
JFR.start
JFR.dump
JFR.check
VM.native_memory
VM.check_commercial_features
VM.unlock_commercial_features
ManagementAgent.stop
ManagementAgent.start_local
ManagementAgent.start
GC.rotate_log
Thread.print
GC.class_stats
GC.class_histogram
GC.heap_dump
GC.run_finalization
GC.run
VM.uptime
VM.flags
VM.system_properties
VM.command_line
VM.version
DanHeidinga commented 5 years ago

Copying from the #5424 duplicate:

We were repeatedly asked by customers for JDK tools which are missing in OpenJ9. List in order of importance (roughly):

jstack jps jstat jinfo

DanHeidinga commented 5 years ago

Based on the discussion in https://github.com/eclipse/openj9/issues/5164#issuecomment-506720816 we should do jcmd next

youurayy commented 5 years ago

Big fan of AdoptOpenJdk+Open9 but not being able to take ad-hoc local heap dumps (w/o firewall piercing etc.) on live/uat systems is a massive wall hit.

pdbain-ibm commented 5 years ago

We're working on it. Part 1 (basic jcmd framework, but no dump support yet) just went in for review. As soon as that is merged, I'll get on the dump support.

pshipton commented 5 years ago

@youurayy note you can create ad-hoc heap dumps already.

youurayy commented 5 years ago

Good to know, thanks. Also I think programmatically thru OpenJ9DiagnosticsMXBean. Still, nice to have the current tooling working w/o changes. Thanks for your work on this.

gkorland commented 4 years ago

I see that the jmap support was already merged, was it released?

JasonFengJ9 commented 4 years ago

I see that the jmap support was already merged, was it released?

It was released at Eclipse OpenJ9 version 0.15.1 [1][2].

[1] https://www.eclipse.org/openj9/oj9_whatsnew.html [2] https://www.eclipse.org/openj9/docs/tool_jmap/

gkorland commented 4 years ago

Strange, I'm still getting this error.

$ jmap 6860
Attaching to process ID 6860, please wait...
Error attaching to process: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process)
sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process)
    at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:411)
    at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
    at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
    at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
    at sun.jvm.hotspot.tools.PMap.main(PMap.java:72)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at sun.tools.jmap.JMap.runTool(JMap.java:201)
    at sun.tools.jmap.JMap.main(JMap.java:130)
JasonFengJ9 commented 4 years ago

@gkorland could you elaborate the scenario? and the -version output from the attaching VM and the target VM.

pshipton commented 4 years ago

@gkorland you need to use the jmap tool from OpenJ9 on an OpenJ9 VM.

pshipton commented 4 years ago 
bin/jmap 31997
exactly one option must be selected
jmap: obtain heap information about a Java process
 Usage:
    jmap <option>* <vmid>
        <vmid>: Attach API VM ID as shown in jps or other Attach API-based tools
        <vmid>s are read from stdin if none are supplied as arguments
    -histo: print statistics about classes on the heap, including number of objects and aggregate size
    -histo:live : Print only live objects
    -J: supply arguments to the Java VM running jmap
NOTE: this utility might significantly affect the performance of the target VM.
At least one option must be selected.
pshipton commented 4 years ago 
bin/jmap 31997 -histo
  num   object count     total size    class name
-------------------------------------------------
    1           5897         235880    [B
    2            816          71808    java.lang.Class
    3           4086          65376    java.lang.String
    4           1995          47880    java.util.HashMap$Node
    5             65          30680    [Ljava.lang.module.ModuleDescriptor$Exports;
    6            379          27288    [Ljava.util.HashMap$Node;
etc