I ran across this:
looks like it could be interesting, but haven’t tried it out.
Bump. This is nice. Not the best UI on the planet but way easier than looking at the raw logs.
At least tell us why said thingy is ‘nice’ :point:
Pretty easy to set up. You’ll need the extra dll/so for PrintAssembly (I think I put the links on the hotspot options wiki page). Grab the app jar itself and one thing their setup doesn’t mention is you also need sl4j logging tools.
Make a shell script/batch file/alias, mine on windows looks like this:
#!/bin/bash
java -cp "C:\Program Files\Java\jdk1.8.0_05\lib\tools.jar;C:\Program Files\Java\jdk1.8.0_05/jre/lib/jfxrt.jar;C:\cygwin64\usr\local\tools\jitwatch-1.0.0-SNAPSHOT.jar;C:\cygwin64\usr\local\tools\slf4j-api-1.7.7.jar" com.chrisnewland.jitwatch.launch.LaunchUI
Launch your program with: [icode]-XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly[/icode]
This will spit out a log file, typically “hotspot_pid{NUM}.log”
Launch the app with your whatever method, set-up where the class & source files live (Config button).
Load the log file with (surprise) Open Log button.
Click the Start button to process the Log.
My reason to try it out (finally) was to see what actual assembly is being used. This is in the triview which shows (side-by-side) source / bytecode and native assembly. You can double click on a JVM op and get a description and mouse hovering over a native opcode give a brief of the opcode.
It looks like it could be handy in a number of ways (well assuming you care about the performance of something). Like seeing if a method isn’t getting inlined and giving a clue of how to restructure your code to fix it.
Actually skimming the wiki for it is a better overview: https://github.com/AdoptOpenJDK/jitwatch/wiki
I haven’t tried this yet: https://groups.google.com/forum/#!topic/jitwatch/VrkZ2vyzXow
I’ve attempted on some toy code and there seems to be some additional tools in the jar which I also haven’t looked at.