Interpreting Mission Control numbers for indy

[Christian Thalinger]

On Sep 18, 2013, at 1:39 AM, Charles Oliver Nutter <headius at headius.com> wrote:

> I've been playing with JMC a bit tonight, running a user's application
> that's about 2x slower using indy than using trivial monomorphic
> caches (and no indy call sites). I'm trying to understand how to
> interpret what I see.
> 
> In the Code/Overview results, where it lists "hot packages", the #1
> and #2 packages are java.lang.invoke.LambdaForm$MH and DMH, accounting
> for over 37% of samples. That sounds high, but I'm willing to grant
> they're hit pretty hard for a fully dynamic application.
> 
> Results in the "Hot Methods" tab show similar things, like
> LambdaForm...invokeStatic_LL_L as the number one result and LambdaForm
> entries dominating the top 50 entries in the profile. Again, I know
> I'm hitting dynamic call sites hard and sampling is not always
> accurate.
> 
> If I look at compilation events, I only see a handful of
> LambdaForm...convert being compiled. I'm not sure if that's good or
> bad. My assumption is that LFs don't show up here because they're
> always being inlined into a caller.
> 
> The performance numbers for the app have me worried too. If I run
> JRuby with stock settings, we will chain up to 6 call targets at a
> call site. The lower I drop this number, the better performance gets;
> when I drop all the way to zero, forcing all invokedynamic call sites
> to fail over immediately to a monomorphic inline cache, performance
> *almost* gets back to the non-indy implementation. This leads me to
> believe that the less I use invokedynamic (or the fewer LFs involved),
> the better. That doesn't bode well.
> 
> I believe the user would be happy to allow me to make these JMC
> recordings available, and I'm happy to re-run with additional events
> or gather other information. The JRuby community has a number of very
> large applications that push the limits of indy. We should work
> together to improve it.

We talked about this in the past.  Can we somehow get access to one of these large applications?

> 
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev