- ppc-aix-port-dev - openjdk.org

AIX build not generating a jre image
by Steve Groeger 25 Oct '17

25 Oct '17

Hi all, When building OpenJDK9 on AIX should the build generate a JRE image ie build/aix-ppc64-normal-server-release/images/jre/bin as well as a JDK image ie build/aix-ppc64-normal-server-release/images/jdk/bin? When I try building on my AIX system it is only generating a JDK image. Is this a issue or is it working correctly? Thanks Steve Groeger Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

7 13

RE: 8188131: [PPC] Increase inlining thresholds to the same as other platforms
by Kazunori Ogata 24 Oct '17

24 Oct '17

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

1 0

Re: Cross compile jdk8u on PPC32
by Volker Simonis 24 Oct '17

24 Oct '17

Hi Radu, ppc32 is currently not supported in the main OpenJDK repositories. You can of course use the zero variant, but that's interpreter only, so the performance won't be great. As far as I know, Azul supports ppc32 but I'm not sure where they are hosting their sources. CC'ed Ivan from Azul who may know. Regards, Volker Radu Andritoiu <raduandritoiu(a)gmail.com> schrieb am Mi. 18. Okt. 2017 um 09:18: > Hello, > > I am new to the community and want to thank you in advance. > > I am trying to cross compile from the latest revision on branch jdk8u162 a > 'client' jvm-variant for PPC32 bit. > Here are some of the errors I am getting: > > > /home/build/build_java/jdk8u_5/hotspot/src/share/vm/runtime/globals.hpp:114:31: > error: c1_globals_ppc.hpp: No such file or directory > ... > > /home/build/build_java/jdk8u_5/hotspot/src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp:34:2: > error: #error "Atomic currently only implemented for PPC64" > ... > > /home/build/build_java/jdk8u_5/hotspot/src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp:33:2: > error: #error "OrderAccess currently only implemented for PPC64" > ... > /home/build/build_java/jdk8u_5/hotspot/src/cpu/ppc/vm/copy_ppc.hpp:30:2: > error: #error "copy currently only implemented for PPC64" > ... > > /home/build/build_java/jdk8u_5/hotspot/src/cpu/ppc/vm/jniTypes_ppc.hpp:49:2: > error: #error "ppc32 support currently not implemented!!!" > ... > > My conclusion was that 'client' jvm-variant is not ported for PPC32. But > the 'servert' jvm-variant did not work either. > My questions are: > 1. Is there a way to compile a 'client' jvm-variant for PPC32? am I doing > something wrong or is this not supported at this time? Should I use a > different revision that jdk8u162? > 2. Is there a way to compile a 'server' jvm-variant for PPC32? Is this > also not supported at this time? > 3. Is there another project/branch besides 'jdk8u' that should work in > cross compiling a jvm for PPC32 bit? > > Thank you, > Radu Andritoiu >

3 2

Re: Cross compile jdk8u on PPC32
by Radu Andritoiu 24 Oct '17

24 Oct '17

Hello, I am still having trouble compiling the 'zero' jvm-variant. I get C/C++ compiling errors I am trying to fix. I looked in 'hotspot/src/cpu' and saw there are source-code folders for different cpu architectures: 'ppc', 'sparc', 'x86', 'zero'. If I use jvm-variant 'zero' when compiling it will try to use the code from 'hotspot/src/cpu/zero'. I looked in the mercurial commit logs and saw (I guess) commits for PPC being done in the folder 'hotspot/src/cpu/ppc'. My question are to build for PPC 32 what source-code folder should I use 'hotspot/src/cpu/zero' or 'hotspot/src/cpu/ppc'? Do I try to build/compile using jvm-variant 'zero' and force it to use the code from 'hotspot/src/cpu/ppc'? Is the source-code from 'hotspot/src/cpu/ppc' onlu for PPC 64? Thank you very much for the help, Radu On Tue, Oct 24, 2017 at 11:46 AM, Andrew Haley <aph(a)redhat.com> wrote: > On 18/10/17 13:20, Radu Andritoiu wrote: > > I am trying to compile jdk8u using jvm-variant "zero" and it asks for > > 'libffi'. > > I read that it uses 'libffi' for JNA to bridge between the interpreter > and > > native code. It does not use JNI. > > That's wrong. Zero supports JNI just fine. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >

3 2

RE: 8188131: [PPC] Increase inlining thresholds to the same as other platforms
by Kazunori Ogata 24 Oct '17

24 Oct '17

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

2 1

8189619: [aix, but changes generated-configure.sh] OpenJDK local disk check not working on AIX
by Thomas Stüfe 20 Oct '17

20 Oct '17

Hi all, May I have a review please for this tiny fix. Fixes the warning checking if we build on a local disk. Bug: https://bugs.openjdk.java.net/browse/JDK-8189619 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8189619-openjdk-local-disk-check… Basically, df -l does not work and has to be substituted with df -T local. Thanks to Stewart X Addison from the AdoptOpenJDK project for figuring this out. I checked the build on linux and AIX, the latter with newer and older AIX versions. At least on newer AIX versions the local build check works correctly. On older versions we still get a misleading warning. There, we may continue to ignore it or just switch it off if it is too annoying. Thank you, Kind Regards, Thomas

2 3

Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0
by Thomas Stüfe 19 Oct '17

19 Oct '17

Hi all, I am wrapping up fixes which did not make it into the repo before the consolidation. Alan already reviewed the last webrev, but I need a second reviewer. Issue: https://bugs.openjdk.java.net/browse/JDK-8186665 Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-ov erflow-in-mincore/webrev.01/webrev Issue text for your convenience: -- In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to retrieve the paging status of an address range. The size of the output buffer for mincore(2) depends on the number of pages in *system page size* in the given memory range (this is spelled out more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I assume the same). The number of pages in the memory range is calculated by MappedByteBuffer.isLoaded() and handed down to Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory range to test. MappedByteBuffer.isLoaded() calculates this number of pages based on jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to os::vm_page_size(). For AIX, os::vm_page_size() may return a page size larger than the system page size of 4K. The reason for this is that on AIX, memory can be backed by different page sizes, usually either 4K or 64K - e.g. posix thread stacks may have 4K pages, java heap (system V shared memory) with 64K pages, but mmap memory is always 4K page backed... But as the OpenJDK code base generally assumes one homogeneous page size for everything - which is usually synonymous with os::vm_page_size() - a decision had to be made which page size to assume as a global system page size, and this may be a larger page size than the 4K system page size mincore(2) assumes. This usually is no problem, but with mincore(2) it is: as the size of the output buffer depends on the number of pages, calculating with a too-large page size causes the output buffer to be too small and hence the buffer overflows. The solution must be to base the size of the mincore output buffer on the system page size. -- Thanks and Kind Regards, Thomas On Thu, Aug 31, 2017 at 9:39 PM, Alan Bateman <Alan.Bateman(a)oracle.com> wrote: > On 31/08/2017 19:01, Thomas Stüfe wrote: > >> Hi Alan, >> >> thank you for your review! >> >> Updated webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-ov >> erflow-in-mincore/webrev.01/webrev/ <http://cr.openjdk.java.net/%7 >> Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/> >> >> I fixed the indention and embellished the comments around the sentinel at >> the end of the buffer somewhat. >> >> This looks okay to me. > > -Alan >

3 10

RE: 8188131: [PPC] Increase inlining thresholds to the same as other platforms
by Kazunori Ogata 19 Oct '17

19 Oct '17

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(a)sap.com> To: Kazunori Ogata <OGATAK(a)jp.ibm.com>, "hotspot-dev(a)openjdk.java.net" <hotspot-dev(a)openjdk.java.net>, "ppc-aix-port-dev(a)openjdk.java.net" <ppc-aix-port-dev(a)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(a)openjdk.java.net; ppc-aix-port-dev(a)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_… Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7E… 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

2 1

Re: AIX build not generating a jre image
by Steve Groeger 18 Oct '17

18 Oct '17

Thomas, Thanks. Glad it is not just me!! Look forward to getting a resolution to this. Thanks Steve Groeger Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -----Thomas Stüfe <thomas.stuefe(a)gmail.com> wrote: ----- To: Volker Simonis <volker.simonis(a)gmail.com> From: Thomas Stüfe <thomas.stuefe(a)gmail.com> Date: 10/18/2017 15:14 Cc: "Lindenmaier, Goetz" <goetz.lindenmaier(a)sap.com>, Steve Groeger <GROEGES(a)uk.ibm.com>, "build-dev (build-dev(a)openjdk.java.net)" <build-dev(a)openjdk.java.net>, "ppc-aix-port-dev(a)openjdk.java.net" <ppc-aix-port-dev(a)openjdk.java.net> Subject: Re: AIX build not generating a jre image On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis <volker.simonis(a)gmail.com> wrote: Hi Goetz, How do our nightly builds look like? Do they create the JRE image? Regards, Volker Goetz is in a meeting. None of our AIX builds creates a JRE image. Works on other platforms. Looks like a bug. I tried to build jre explicitly (make jre-image); build finishes sucessfully but still no jre. I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. ..Thomas Lindenmaier, Goetz <goetz.lindenmaier(a)sap.com> schrieb am Mi. 18. Okt. 2017 um 14:56: > Hi Steve, > > I think this is an error. > We never decided not to generate a jre image as far as I know. > > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces(a)openjdk.java.net] On Behalf Of Steve Groeger > > Sent: Mittwoch, 18. Oktober 2017 14:34 > > To: ppc-aix-port-dev(a)openjdk.java.net > > Subject: AIX build not generating a jre image > > > > Hi all, > > > > When building OpenJDK9 on AIX should the build generate a JRE image ie > > build/aix-ppc64-normal-server-release/images/jre/bin as well as a JDK > image > > ie build/aix-ppc64-normal-server-release/images/jdk/bin? When I try > > building on my AIX system it is only generating a JDK image. Is this a > issue or is > > it working correctly? > > > > > > Thanks > > Steve Groeger > > Java Runtimes Development > > IBM Hursley > > IBM United Kingdom Ltd > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges(a)uk.ibm.com <mailto:groeges@uk.ibm.com> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

RFR(xs): 8187228: [aix] make data segment page size 64K by default
by Thomas Stüfe 18 Oct '17

18 Oct '17

Hi all, may I please have a review for the following AIX-only patch. Issue: https://bugs.openjdk.java.net/browse/JDK-8187228 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data -segment-page-size-64K-by-default/webrev.00/webrev/ It changes the default page size for the data segment (C-heap and Posix Thread Stacks) to 64K. For completeness and simplicity sake, it also changes default page size for text segment and primordial thread stacl to 64K, but that does not matter much. For more details, please see the issue description. Thank you, Thomas

3 8