On Wed, Dec 14, 2011 at 2:54 AM, Robert Klemme
<shortcutter / googlemail.com> wrote:
>> jruby -J-Xrunhprof ... # run with object allocation profiling,
>> tracking allocation call stacks 5 deep
>> jruby -J-Xrunhprof:depth=10 ... # ... call stacks 10 deep
>
> That's a full profiler. You can remedy the performance hit with option
> cpu=samples significantly. The inaccuracy introduced by this is
> probably negligible since hotspots will still be at the top. Results
> can be analyzed with the free tool HPJMeter from HP.
> http://www.javaperformancetuning.com/tools/hpjmeter/index.shtml

For CPU, yes. This is not CPU profiling, however, and runhprof does
not have a sampling mode for allocations.

VisualVM, on the other hand, does have such a mode. It's usually my
second tool of choice for allocation analysis.

And of course you're right...there's many, many other tools for JVM
that can give some of the same and some different information. Most
work just dandy with JRuby.

> There is a more lightweight alternative for just looking at instance
> counts and sizes per class:
>
> $ jmap -histo <pid>

Indeed. jmap is very useful for getting a "moment in time" snapshot of
in-memory objects.

I've covered several of these tools in my memory-related series of blog posts:

http://blog.headius.com/2010/07/browsing-memory-jruby-way.html

http://blog.headius.com/2010/07/finding-leaks-in-ruby-apps-with-eclipse.html

http://blog.headius.com/2010/07/browsing-memory-with-ruby-and-java.html

And similar (possibly duplicate) posts on EY blog:

http://www.engineyard.com/blog/2010/monitoring-memory-with-jruby-part-1-jhat-and-visualvm/

http://www.engineyard.com/blog/2010/montoring-memory-with-jruby-part-2-eclipse-memory-analyzer/

Tip of the iceberg.

- Charlie