Profiling should not bomb out trying to find method name

Very interesting! I wonder what method didn't get registered properly.

I will likely patch this for 1.6 to ignore methods it can't find, but ideally we'd figure out which one it is. Perhaps once I have it patched you can try to run a graph profile and ascertain which method is missing?

I do notice that the profiling is set up to use the "global runtime" when printing, which could be the source of this problem. In essence, if you're running a setup where there's multiple live JRuby instances, it will show incorrect profile results by treating numbers from all runtimes as though they were in the first-created runtime. Is that the case for your example?

Ok, I've made fixes that should prevent this from blowing up, but I'd like to find out what method went missing. Even GC shouldn't cause that, since we keep a hard reference to the original methods (so we can display all interesting info about them). The fixes I made will be in JRuby 1.6...once that's out (tomorrow, please try to reproduce and see if you see "<unknown>" entries in the profile. If you can figure out what's missing, I'll be able to figure out why and solve the root cause.

commit 43422df208abbeddec80c6492af80cdb88b8936c
Author: Charles Oliver Nutter <headius@headius.com>
Date: Mon Mar 14 19:32:54 2011 -0500

Fix JRUBY-5583: Profiling should not bomb out trying to find method name

Two fixes, but I'm going to leave the bug open to try to determine why a method was missing from the profile table:

• Make profiling table growth synchronized, for cases where methods are being defined across threads
• If a method can't be found at display time, replace it with "<unknown>". This should not happen.

This issue ("<unknown>" methods) still exists on JRuby 1.6.6 (ruby-1.8.7-p357) (2012-01-30 5673572), also in Rails (3.0.8). Any plans to address this issue?

Guys, any solution for "<unknown>" methods? It's currently really hard to use jruby profiler.

This seems like it's probably related to the limit on how many methods we'll profile; that limit is currently set to 100000, but it seems like it's not working quite right.

I'll play with this a bit today and see if I can make the limit sufficiently high and working properly.

I'm going to be optimistic and assume recent fixes on master have cured the last issues here.

The primary of these fixes repaired how we limit the number of profiled methods, so that it would not blow up if it reached the upper limit. Another fix I'm making momentarily will work harder to get the "real" method being profiled, which should avoid intermediate wrappers (like aliases, etc) from confusing the profile. The last change allows configuring the upper bound of profilable methods.

If you hit the upper bound, you should see the following message logged somewhere:

warning: method count exceeds max of 100000; no new methods will be profiled

You can bump up the limit by passing -Xprofile.max.methods=###### to JRuby or -J-Djruby.profile.max.methods=###### to the JVM where the default is 100000.

The additional change:

commit c048cc34dd94958b7ec39b3ba37281b8e2be5b5e
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Aug 30 11:18:34 2012 -0500

    Make profiling dig deeper to get the "real" method being called.

:100644 100644 6c49169... 3c149cf... M	src/org/jruby/internal/runtime/methods/ProfilingDynamicMethod.java

thanks Charles, is this commit going to be applied to 1.6.7 branch also?

I had not planned on it, but if you put together a working pull request I'll merge it.