8188131: [PPC] Increase inlining thresholds to the same as other platforms

Fri Oct 20 06:31:47 UTC 2017

Hi Goetz,

Thank you for your comment.  OK, I'll evaluate the patch more by comparing 
the minimum code cache sizes and the performance on the cache size.

It is helpful if you could explain what is the difference of the JIT 
behavior when the code cache is large enough and when it is the minimum 
size.  It seems almost the same to me because all the methods that needed 
to be compiled should be compiled in both cases, but I may miss something.

By the way, the benchmark I confirmed performance improvement was TPC-DS 
q96, but I measured the code cache size of SPECjbb2015 by my mistake. I'll 
compare the minimum code cache sizes and the performance of both 
benchmarks, as this patch will affect all applications.

Regards,
Ogata

From:   "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
To:     Kazunori Ogata <OGATAK at jp.ibm.com>, "Doerr, Martin" 
<martin.doerr at sap.com>
Cc:     "ppc-aix-port-dev at openjdk.java.net" 
<ppc-aix-port-dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net" 
<hotspot-dev at openjdk.java.net>
Date:   2017/10/19 20:03
Subject:        RE: 8188131: [PPC] Increase inlining thresholds to the 
same as other platforms

Hi Kazunori, 

To me, this seems to be a very large increase.
Considering that not only the required code cache size but also the 
compiler cpu time will increase in this magnitude, this seems to be 
a rather risky step that should be tested for its benefits on systems
that are highly contended.

In this case, you probably had enough space in the code cache so that
no recompilation etc. happened. 

To further look at this I could think of 
1. finding the minimal code cache size with the old flags where 
   the JIT is not disabled
2. finding the same size for the new flag settings 
   --> How much more is needed for the new settings?

Then you should compare the performance with the bigger 
code cache size for both, and see whether there still is performance
improvement, or whether it's eaten up by more compile time. 
I.e. you should have a setup where compiler threads and application
threads compete for the available CPUs.

What do you think?

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Kazunori Ogata
> Sent: Donnerstag, 19. Oktober 2017 08:43
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
> Subject: RE: 8188131: [PPC] Increase inlining thresholds to the same as 
other
> platforms
> 
> Hi Martin,
> 
> Thank you for your comment.  I checked the code cache size by running
> SPECjbb2015 (composite mode, i.e., single JVM mode, heap size is 31GB).
> 
> The used code cache size was increased by 4.5MB from 41982Kb to 47006Kb
> (+12%).  Is the increase too large?
> 
> 
> The raw output of -XX:+PrintCodeCache are:
> 
> === Original ===
> CodeHeap 'non-profiled nmethods': size=652480Kb used=13884Kb
> max_used=13884Kb free=638595Kb
>  bounds [0x00001000356f0000, 0x0000100036480000, 0x000010005d420000]
> CodeHeap 'profiled nmethods': size=652480Kb used=26593Kb
> max_used=26593Kb
> free=625886Kb
>  bounds [0x000010000d9c0000, 0x000010000f3c0000, 0x00001000356f0000]
> CodeHeap 'non-nmethods': size=5760Kb used=1505Kb max_used=1559Kb
> free=4254Kb
>  bounds [0x000010000d420000, 0x000010000d620000, 0x000010000d9c0000]
>  total_blobs=16606 nmethods=10265 adapters=653
>  compilation: enabled
> 
> 
> === Modified (webrev.00) ===
> CodeHeap 'non-profiled nmethods': size=652480Kb used=18516Kb
> max_used=18516Kb free=633964Kb
>  bounds [0x0000100035730000, 0x0000100036950000, 0x000010005d460000]
> CodeHeap 'profiled nmethods': size=652480Kb used=26963Kb
> max_used=26963Kb
> free=625516Kb
>  bounds [0x000010000da00000, 0x000010000f460000, 0x0000100035730000]
> CodeHeap 'non-nmethods': size=5760Kb used=1527Kb max_used=1565Kb
> free=4232Kb
>  bounds [0x000010000d460000, 0x000010000d660000, 0x000010000da00000]
>  total_blobs=16561 nmethods=10295 adapters=653
>  compilation: enabled
> 
> 
> Regards,
> Ogata
> 
> 
> 
> 
> From:   "Doerr, Martin" <martin.doerr at sap.com>
> To:     Kazunori Ogata <OGATAK at jp.ibm.com>, "hotspot-
> dev at openjdk.java.net"
> <hotspot-dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>
> Date:   2017/10/18 19:43
> Subject:        RE: 8188131: [PPC] Increase inlining thresholds to the
> same as other platforms
> 
> 
> 
> Hi Ogata,
> 
> sorry for the delay. I had missed this one.
> 
> The change looks feasible to me.
> 
> It may only impact the utilization of the Code Cache. Can you evaluate
> that (e.g. by running large benchmarks with -XX:+PrintCodeCache)?
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf
> Of Kazunori Ogata
> Sent: Freitag, 29. September 2017 08:42
> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> Subject: RFR: 8188131: [PPC] Increase inlining thresholds to the same as
> other platforms
> 
> Hi all,
> 
> Please review a change for JDK-8188131.
> 
> Bug report:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bugs.openjdk.java.net_browse_JDK-
> 2D8188131&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=ExKSiZAany_n7vS453MD
> 73lAZxkNhGsrlDkk-
> YUYORQ&s=ic27Fb2_vyTSsUAPraEI89UDJy9cbodGojvMw9DNHiU&e=
> 
> Webrev:
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cr.openjdk.java.net_-
> 7Ehorii_8188131_webrev.00_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=ExKSiZAany_n7vS453MD
> 73lAZxkNhGsrlDkk-YUYORQ&s=xS8PbLyuVtbOBRDMIB-
> i9r6lTggpGH3Np8kmONkkMAg&e=
> 
> 
> This change increases the default values of FreqInlineSize and
> InlineSmallCode in ppc64 to 325 and 2500, respectively.  These values 
are
> the same as aarch64.  The performance of TPC-DS Q96 was improved by
> about
> 6% with this change.
> 
> 
> Regards,
> Ogata
> 
> 
> 