Profiling + Indy

[Tom Rodriguez]

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 at 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
> <headius at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev