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

[White, Derek]

Hi All,

I was trying to see where x86's 1000 value originally came from, and got as far back as JDK7. Earlier there was one shared value for InlineSmallCode (1000), but SPARC-specific values were added in JDK 7 for performance reasons. See JDK-6821700 (redacted). 

I was expected to see something like "increased for Method Handles". Or it could be that the method handles implementation (and the like) were tuned to fit in 1000.

In any case, I agree with Andrew Dinn. We don't have a reason the correct answer is exactly 1500, but I'm pretty sure that the answer isn't 1000. We might as well match the crowd.

Yes, this only affects the non-TieredCompilation case, so only over-tweaking config hounds and JVM performance analysis nuts will notice. But I know some people like that ��.

 - Derek

> -----Original Message-----
> From: aarch64-port-dev [mailto:aarch64-port-dev-
> bounces at openjdk.java.net] On Behalf Of Andrew Dinn
> Sent: Monday, July 24, 2017 10:55 AM
> To: Andrew Haley <aph at redhat.com>; aarch64-port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] -XX:InlineSmallCode=1500
> 
> On 24/07/17 15:46, Andrew Haley wrote:
> > On 24/07/17 15:37, Andrew Dinn wrote:
> >> 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?
> >
> > Yes.  This explains another mystery: we only saw the slowdown with
> > Doug's test when using -XX:-TieredCompilation.  So, it looks like this
> > is already fixed for everything, as long as tiered compilation is
> > enabled.  I guess it doesn't much matter whether we change it or not
> 
> Not much. It would probably be more rational to align the two settings so
> AArch64 is consistently in the SPARC ballpark ... or we could just leave it as a
> puzzle for future maintainers.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------