Netbeans has a profiler built in, though I don't know how well it works and I don't know if it's been updated for 292. The Sun Studio Analyzer does a very good job capturing profiles without a lot of overhead though it only runs on Solaris and Linux. The very latest version supports 292 but I don't know if the latest released version does. The linux support is relatively recent too so I don't know how good it is.
I do wish we had a simple profiler built in. The current Xprof is pretty useless. One problem you will encounter is that method handles are all anonymous so I mapping profiles back to your code might be hard. This is a known hole but I don't know that anyone is thinking about how this should work. tom On Oct 13, 2011, at 8:53 PM, Charles Oliver Nutter wrote: > FWIW, option 2 (hprof) seems like a no-show on u2b08: > > headius@headius-vbox-ubuntu:~/projects/redblack$ > JAVA_HOME=~/jdk1.7.0_02/ ../jruby/bin/jruby -X+C > -J-Xrunhprof:cpu=times bm1.rb 20 > HPROF ERROR: Unknown constant > [../../../src/share/demo/jvmti/java_crw_demo/java_crw_demo.c:693] > [hprof_init.c:210] > HPROF TERMINATED PROCESS > > So I'm stuck with sampling. > > - Charlie > > On Fri, Oct 14, 2011 at 3:52 AM, Charles Oliver Nutter > <head...@headius.com> wrote: >> I'm looking to get back into JRuby + Indy work now that the heaviest >> conferences are behind me. Part of this involves running larger >> benchmarks where the hot spots may not be apparent at a glance. In >> order to investigate performance on such benchmarks, I will want to do >> some profiling. But what should I use? >> >> For really egregious problems, the sampling profiler (-Xprof) "sort >> of" works. It's grossly inaccurate when there's no stand-out hotspot, >> but if something is incredibly bad it usually shows it. So that's >> option 1. >> >> There's -Xrunhprof:cpu=times, which is more accurate, but the impact >> to running code is enormous, there's no way to filter out >> uninteresting code (like JDK core), and I have no idea if it works >> properly with indy (given that there's ongoing work to make JVMTI + >> indy play nice). That's option 2. >> >> Are either of these options any good? What else do you recommend? >> >> - Charlie >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
