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@openjdk.java.net] On Behalf Of Kazunori Ogata Sent: Donnerstag, 19. Oktober 2017 08:43 To: Doerr, Martin <martin.doerr@sap.com> Cc: ppc-aix-port-dev@openjdk.java.net; hotspot-dev@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@sap.com> To: Kazunori Ogata <OGATAK@jp.ibm.com>, "hotspot- dev@openjdk.java.net" <hotspot-dev@openjdk.java.net>, "ppc-aix-port-dev@openjdk.java.net" <ppc-aix-port-dev@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@openjdk.java.net] On Behalf Of Kazunori Ogata Sent: Freitag, 29. September 2017 08:42 To: hotspot-dev@openjdk.java.net; ppc-aix-port-dev@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