On Sep 18, 2013, at 1:39 AM, Charles Oliver Nutter <head...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
