[aarch64-port-dev ] -XX:InlineSmallCode=1500

[Andrew Dinn]

On 24/07/17 14:06, Andrew Haley wrote:
> Doug Lea sent me an interesting benchmark that was running much faster
> on the Oracle ARM64 JDK than on the AArch64 port.  To cut a fairly
> long story short, it turns out that it was because of inlining: the
> aarch64-port's threshold for inlining a method is 1000 bytes, arm64's
> is 1500 bytes.  And this can make a very substantial difference in
> some cases.
> 
> I've been pondering whether we should change ours to match.  On the
> one hand, we'd get better performance sometimes, but it would generate
> significantly more code in some cases, with all of the consequent
> expansion of code cache size, etc.  On the other hand, maybe the
> Oracle's 1500 bytes is based on something real.  But I'm not seeing a
> large increase in compiled code size for aarch64 versus x86, certainly
> much less than 50%, so I'm tempted to leave InlineSmallCode where it is.
> 
> Answers on a postcard...

Well, I may not be much use here because I had to grep the code to see
exactly how this worked. Anyway, in the process I noted that x86
defaults this to 1000, SPARC and ppc to 1500 and s390 to 2000. That
might suggest a relationship to the nature of the respective instruction
encodings or it might simply be random stabs at a workable figure? One
could probably argue that the AArch64 instruction set ought to be in the
same ballpark as SPARC or PPC, a ballpark not occupied by x86. I
wouldn't know how s390 fits into that picture.

I also noticed that if you specify CompilationPolicy=3 (i.e.
AdvancedThresholdPolicy) the InlineSmallCode values get bumped up to
2000 on x86 and 2500 on SPARC and AArch64, once again suggesting
disjoint ballparks:

  // Some inlining tuning
#ifdef X86
  if (FLAG_IS_DEFAULT(InlineSmallCode)) {
    FLAG_SET_DEFAULT(InlineSmallCode, 2000);
  }
#endif

#if defined SPARC || defined AARCH64
  if (FLAG_IS_DEFAULT(InlineSmallCode)) {
    FLAG_SET_DEFAULT(InlineSmallCode, 2500);
  }
#endif

I didn't recall writing that code. So, I looked up who did and found
that the SPARC case handling goes way back b-but ... the later addition
of the 'defined AARCH64' disjunct was by one Ed Nevill on Jun 10 2015!
Maybe he applied actual science and did some measurements? I wouldn't be
surprised if that were so. We could perhaps do the same? Or just rely on
him having got it right?

Interestingly, there was also a comment in hotspot test
compiler/c2/Test6910605_2.java saying

  "Added InlineSmallCode=2000 to guaranty [sic] inlining of
StringBuilder::append() to allow scalar replace StringBuilder object."

Is this benefit anywhere near the vicinity of the improvement arrived at
in Doug's benchmark test?

regards,


Andrew Dinn
-----------