Interpreting Mission Control numbers for indy

George Marrows george.marrows at googlemail.com
Thu Sep 19 01:14:45 PDT 2013


Christian --

Duncan Macgregor and I have a large desktop application that makes very
heavy use of indy.
As Duncan reported recently, we're also seeing increased memory usage and
(probably) decreased performance under u40.

Will contact you privately with details of how we can get you access.

-- George


On Thu, Sep 19, 2013 at 3:01 AM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:

>
> 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
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130919/d53a132a/attachment.html 


More information about the mlvm-dev mailing list