Closed retronym closed 2 years ago
Hi, I added support for this many years ago but I can't remember the conditions to trigger it. I think if the fully qualified main class is the same then it should preserve the UI state (or at least there should be an option for this).
The 2nd request could probably be implemented easily with -D switches to set system properties.
Thanks for the suggestions, I'll try and get them added.
OK, I've found the code for this but it's currently broken. It relies on the vm_arguments->command value in the log:
<vm_arguments>
<args>
-XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:LogFile=/Users/chrisnewland/IdeaProjects/jitwatch/sandbox/sandbox.log -XX:+PrintAssembly -XX:-BackgroundCompilation
</args>
<command>
SimpleInliningTest
</command>
Will fix asap.
Thanks.
As context, the build for the Scala Programming Language contains JMH based microbenchmarks, and I've written a command in our build that generates the file with the classpath and sourcepath suitable for -Djitwatch.config.file=jitwatch.properties
.
This goes a long way to making JITWatch easy to use (for me on regular basis and for first-time users).
Being able to pass in the hotspot.log
location as a command line parameter and the entry-point for the UI would let me turn more of the documentation into automation.
I'll also be able to extract these conveniences into the sbt-jmh
build plugin to make them available for other Scala projects built with SBT.
Hi Jason, I've implemented the "launch with logfile and focus on member" on this branch: https://github.com/AdoptOpenJDK/jitwatch/tree/issue_302_launch_with_logfile
The system properties you need to set are:
jitwatch.logfile
(absolute path to HotSpot log file)
and
jitwatch.focus.member
(a method signature in LogCompilation format - see below)
So for example:
mvn clean compile exec:java -Djitwatch.logfile=/home/chris/IdeaProjects/jitwatch-gh/sandbox/sandbox.log -Djitwatch.focus.member="java/lang/String indexOf (II)I"
Let me know if that works for you?
Cheers,
Chris
Yep, that works. Thanks!
The only change I needed to make was:
$ git diff
diff --git a/launchUI.sh b/launchUI.sh
index 3e7fefd..e091ae4 100755
--- a/launchUI.sh
+++ b/launchUI.sh
@@ -29,4 +29,4 @@ CLASSPATH=$CLASSPATH:core/build/classes/java/main
CLASSPATH=$CLASSPATH:ui/build/classes/java/main
CLASSPATH=$CLASSPATH:ui/src/main/resources
-"$JAVA_HOME/bin/java" -Djava.library.path=$JAVA_HOME/lib/amd64 -cp "$CLASSPATH" $@ org.adoptopenjdk.jitwatch.launch.LaunchUI
+"$JAVA_HOME/bin/java" -Djava.library.path=$JAVA_HOME/lib/amd64 -cp "$CLASSPATH" "$@" org.adoptopenjdk.jitwatch.launch.LaunchUI
To do the same thing using launchUI.sh
.
One extra convenience would be to support a regex in jitwatch.focus.member
for the common case where the method is not overloaded and it's a bit of a hassle to construct the parameter descriptor.
Although I can have my tooling grep that hotspot log if that's too awkward.
$ grep -E -o "scala.collection.mutable.ArrayOpsBenchmark.insertInteger .*?\'" /Users/jz/code/scala/test/benchmarks/target/hotspot.log | head -1
scala/collection/mutable/ArrayOpsBenchmark insertInteger (Lorg/openjdk/jmh/infra/Blackhole;)V'
I've updated our tooling/documentation in preparation for this: https://github.com/scala/scala/pull/8000
Thanks Jason, I've merged this branch to master along with the launchUI.sh fix. I'll take a look at the UI state on reload shortly. Cheers, Chris
When in a workflow of tweaking code, collecting hotspot logs, then analysing with JITWatch, the clicks to navigate back to the method of interest interrupt the flow.
It would be great if the UI could at least restore the selection of the main tree view. It would be better yet to re-open the TriView panel (assuming the method still exists in the most recent run.)
The other productivity improvement would be to allow command line options to trigger the "Start" with a particular hotspot.log and opening of a TriView at a given method.