Hi Goetz, Thank you for clarification and re-directing discussion to hotspot-compiler-dev ML. I understood the intention of the measurement around the lower bound of the code cache size. I'll post the results when I finish measurements. Regards, Ogata From: "Lindenmaier, Goetz" <goetz.lindenmaier@sap.com> To: Kazunori Ogata <OGATAK@jp.ibm.com>, "'hotspot-compiler-dev@openjdk.java.net'" <hotspot-compiler-dev@openjdk.java.net> Cc: "Doerr, Martin" <martin.doerr@sap.com>, "ppc-aix-port-dev@openjdk.java.net" <ppc-aix-port-dev@openjdk.java.net> Date: 2017/10/24 16:30 Subject: RE: 8188131: [PPC] Increase inlining thresholds to the same as other platforms Hi Ogata,

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 If the code cache is not large enough, code can get evicted and recompiled. Then the compiler threads keep concurring for cpu with the application threads, assuming the application utilizes all cpus for application threads. Generating bigger code obviously will bring the application faster into this situation.

Please, as this is a compiler issue, it should be discussed on hotspot-compiler-dev. Best regards, Goetz.

-----Original Message----- From: Kazunori Ogata [mailto:OGATAK@jp.ibm.com] Sent: Freitag, 20. Oktober 2017 08:32 To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com> Cc: hotspot-dev@openjdk.java.net; Doerr, Martin <martin.doerr@sap.com>; ppc-aix-port-dev@openjdk.java.net Subject: RE: 8188131: [PPC] Increase inlining thresholds to the same as other platforms

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@sap.com> To: Kazunori Ogata <OGATAK@jp.ibm.com>, "Doerr, Martin" <martin.doerr@sap.com> Cc: "ppc-aix-port-dev@openjdk.java.net" <ppc-aix-port-dev@openjdk.java.net>, "hotspot-dev@openjdk.java.net" <hotspot-dev@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@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