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

John Rose john.r.rose at oracle.com
Wed Sep 8 00:10:33 PDT 2010

On Sep 7, 2010, at 11:34 PM, Charles Oliver Nutter wrote:

> I'll give that a shot, Tom, thanks. Should have thought of it myself.

Also, to make the compiler really spill its guts, try +LogCompilation (google for the wiki page that discusses it).

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.

(Smoothing out these heuristics would be a great post-graduate thesis, IMO.)

For an example of experimenting with the inlining heuristics see:

Any such use of the tuning flags must be regarded as purely experimental, but tuning experiments can lead to real improvements.

-- John

P.S One recent change (to type profiles, not inlining heuristics) was motivated by a performance tuning exercise similar to the present one:

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)

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.

More information about the hotspot-compiler-dev mailing list