On Wed, Dec 14, 2011 at 9:04 AM, Charles Oliver Nutter
<headius / headius.com> wrote:
> On Tue, Dec 13, 2011 at 8:03 PM, Chuck Remes <cremes.devlist / mac.com> wrote:

>> Also, I'm not certain what you mean by "I'm sure it's singleton somewhere." I know what a singleton is, but I don't understand your use of it in this context. Elaborate, please.
>
> Actually, it may not be a singleton object/class, now that I think
> about it. Someone, somewhere is doing a Class.new {  ¨Β ¨οσινιμας© ιξ
> critical path code.
>
>> I'll take a shot at reducing my object allocation. More information on how many of each type of object is being allocated would be a wonderful statistic to have. Also, if there were a way to trace that allocation back to aarticular file and line number (for those cases where the same object is allocated in multiple places), that would be a killer profiling feature. <hint, hint>
>
> Indeed it would. Luckily, the JVM already provides it.
>
> It will be very slow, but Sun/Oracle/OpenJDK has an object allocation
> profiler built in. Examples:
>
> 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

There is a more lightweight alternative for just looking at instance
counts and sizes per class:

$ jmap -histo <pid>

Process usually can be found via jps, ps or other means.

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/