[jvm-l] Re: Small static method marked not entrant, inlining reversed?

[Charles Oliver Nutter]

On Wed, Sep 8, 2010 at 7:10 AM, John Rose <john.r.rose at oracle.com> wrote:
> Also, to make the compiler really spill its guts, try +LogCompilation (google for the wiki page that discusses it).

For whatever reaons, PrintInlining wouldn't show anything but
intrinsics. Perhaps it's my build. I opted to use LogCompilation
instead.

> Your prejudice against "fat" bytecodes corresponds somewhat to the HotSpot inlining heuristics.  HotSpot strongly prefers to inline small methods, and the algorithm has a non-linear side to it.  Two cold methods of 30 bytecodes each are much more likely to get inlined than one method of 60 bytecodes.   Likewise for a hot call to two methods of 300 bytecodes each.

I do a periodic survey of LogCompilation output for key parts of JRuby
(like the parser) to ensure we haven't grown any methods beyond
various inlining budgets. You get the idea pretty quickly that Hotspot
hates big method bodies...

> For an example of experimenting with the inlining heuristics see:
>  http://blogs.sun.com/jrose/entry/an_experiment_with_generic_arithmetic
>  http://blogs.sun.com/jrose/resource/jsr292/SumWithIndy.zip
>
> Any such use of the tuning flags must be regarded as purely experimental, but tuning experiments can lead to real improvements.

I'll give that another read. I feel like the logic I have in place for
inserting direct static (typed) invocations to "hot" methods at a
JRuby call site is a good step forward, but the bytecode size increase
is a harsh mistress. Add to that this seeming problem with inlining a
bimorphic invokeinterface (that's actually monomorphic from the base
implementation) and you have a very frustrated JRuby compiler writer.

> P.S One recent change (to type profiles, not inlining heuristics) was motivated by a performance tuning exercise similar to the present one:
>  http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b29a725c43c
>
> The improvement is to collect type profiles up at the 'if' instead of down at the cast in idioms like this:
>  if (x instanceof C)
>    ((C)x).somethingFast();
>  else
>    MyRuntime.somethingSlow(x);
>
> With a successful type profile, this will be able to collapse like this:
>  if (x.getClass() != C42.class)  trap();
>  inline C42.somethingFast(x);
>
> HotSpot was already collecting type profiles at the cast and the invokevirtual, but not at the instanceof.

How about at an invokeinterface? It appears to collect type profiles,
but for only resolving to the immediate types, and not the actual
method-to-be-invoked or the common superclass of both that actually
provides the implementation...

At this point I'm also not above exploring C2, if it's possible to
localize this case to something I can consume. I'll have a gander at
your patches in the morning.

- Charlie