From HORIE at jp.ibm.com Wed Oct 4 02:27:26 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 4 Oct 2017 11:27:26 +0900 Subject: Fw: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Message-ID: Dear all, I forward the mail exchanges with Martin to ppc-aix-port-dev. As I noted below, a latest webrev is following. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Forwarded by Michihiro Horie/Japan/IBM on 2017/10/04 11:23 ----- From: Michihiro Horie/Japan/IBM To: martin.doerr at sap.com Cc: hotspot-dev at openjdk.java.net Date: 2017/10/03 22:12 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX I noticed that vsra() etc. fill 1u in higher bits, sorry. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: Michihiro Horie/Japan/IBM To: "Doerr, Martin" Cc: "hotspot-dev at openjdk.java.net" Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Date: Tue, Oct 3, 2017 9:27 PM Hi Martin, Thank you very much for your further important comments. I understand VSR52-63 should not be used for now. Fixed webrev is: http://cr.openjdk.java.net/~mhorie/8188139/webrev.03/ Best regards, -- Michihiro, IBM Research - Tokyo "Doerr, Martin" ---2017/10/03 00:24:21---Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_ From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" Date: 2017/10/03 00:24 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_reg needs to be limited to the usable ones. (Comment should be fixed.) Unfortunately, the ABI specifies VR20-31 which map to VSR52-63 as nonvolatile. They could be used by the C code, but are not getting saved and restored. I guess it?s unlikely that there will be anything useful in these registers, but you never know what (future) compilers will do. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 2. Oktober 2017 16:58 To: Doerr, Martin Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, >the floating point registers are mapped into VSR0-31. Hence, you can?t use them for allocation in vectorx_reg. Thank you very much for your helpful comments. This is one of the points I did not understand on how to handle VSR even though there are duplication with FPR. I understand there is no trick and I need to use only VSR32-63 in this case. Updated webrev is : http://cr.openjdk.java.net/~mhorie/8188139/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into V"Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for al From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" Date: 2017/10/02 18:47 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can?t use them for allocation in vectorx_reg. Or how do you prevent the FP registers from getting killed? Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Michihiro Horie Sent: Samstag, 30. September 2017 17:22 To: Vladimir Kozlov Cc: Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Vladimir, Gustavo, Thanks a lot for your comments. I updated the webrev: http://cr.openjdk.java.net/~mhorie/8188139/webrev.01/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks,Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks, From: Vladimir Kozlov To: Gustavo Romero , hotspot-dev at openjdk.java.net Cc: Michihiro Horie , ppc-aix-port-dev at openjdk.java.net, "Simonis, Volker" Date: 2017/09/30 06:40 Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX I am fine with it for these changes. Thanks, Vladimir On 9/29/17 12:19 PM, Gustavo Romero wrote: > Hi Vladimir, > > On 29-09-2017 16:00, Vladimir Kozlov wrote: >> I looked on shared code. One comment - change in opto/type.cpp affects s390. > > Do you strongly oppose to split PPC64 and s390 like? > > diff -r e93ed1a09240 src/share/vm/opto/type.cpp > --- a/src/share/vm/opto/type.cpp Tue Aug 08 22:57:34 2017 +0000 > +++ b/src/share/vm/opto/type.cpp Fri Sep 29 15:17:17 2017 -0400 > @@ -67,7 +67,13 @@ > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > -#elif defined(PPC64) || defined(S390) > +#elif defined(PPC64) > + { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > + { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > + { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX > + { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > + { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > +#elif defined(S390) > { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > > > Kind regards, > Gustavo > >> Vladimir >> >> On 9/29/17 2:37 AM, Michihiro Horie wrote: >>> Dear all, >>> >>> Would you please review the following change? >>> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8188139&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=8qV6XGFLseFXm282dspqVrhPluKMgjJ1JVqnM92Ttt4&e= >>> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8188139_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=hwk_4PJ5tU211eAdQ9txxjx_5WM9b6q4QXaZvsU98yI&e= >>> >>> This change introduces to use VSX for Superword Level Parallelization, concretely VSX instructions are emitted for Replicate[BSIFDL] nodes in ppc.ad. >>> Since I am not familiar with the hotspot's register allocation and the TOC use in POWER, I would be very grateful to have any comments to improve the change. >>> >>> In addition, the change includes some minor fixes in assembler_ppc.inline.hpp. I think there are some instructions that should have 1u in higher bits. >>> >>> >>> I used the attached micro benchmark. >>> /(See attached file: ArraysFillTest.java)/ >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1C435023.gif Type: image/gif Size: 105 bytes Desc: not available URL: From martin.doerr at sap.com Wed Oct 4 07:44:14 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 4 Oct 2017 07:44:14 +0000 Subject: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX In-Reply-To: References: Message-ID: <1f107ecc19bc4602a983b047997d207c@sap.com> Hi Michihiro, unfortunately, an older version of your change was pushed. Can you create a new bug for your latest changes, please? Please note that the "// nv!" does not help. These comments may help the reader but not the VM. You need to take them out and replace by a comment. (You can't take the nv FP registers as a reference because they get saved and restored in the entry frame, so nv is only a comment there.) Thanks for contributing this change. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 04:27 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Hiroshi H Horii ; Doerr, Martin ; Gustavo Romero ; Kazunori Ogata Subject: Fw: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Dear all, I forward the mail exchanges with Martin to ppc-aix-port-dev. As I noted below, a latest webrev is following. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Forwarded by Michihiro Horie/Japan/IBM on 2017/10/04 11:23 ----- From: Michihiro Horie/Japan/IBM To: martin.doerr at sap.com Cc: hotspot-dev at openjdk.java.net Date: 2017/10/03 22:12 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ I noticed that vsra() etc. fill 1u in higher bits, sorry. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: Michihiro Horie/Japan/IBM To: "Doerr, Martin" > Cc: "hotspot-dev at openjdk.java.net" > Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Date: Tue, Oct 3, 2017 9:27 PM Hi Martin, Thank you very much for your further important comments. I understand VSR52-63 should not be used for now. Fixed webrev is: http://cr.openjdk.java.net/~mhorie/8188139/webrev.03/ Best regards, -- Michihiro, IBM Research - Tokyo "Doerr, Martin" ---2017/10/03 00:24:21---Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_ From: "Doerr, Martin" > To: Michihiro Horie > Cc: "hotspot-dev at openjdk.java.net" > Date: 2017/10/03 00:24 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_reg needs to be limited to the usable ones. (Comment should be fixed.) Unfortunately, the ABI specifies VR20-31 which map to VSR52-63 as nonvolatile. They could be used by the C code, but are not getting saved and restored. I guess it's unlikely that there will be anything useful in these registers, but you never know what (future) compilers will do. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 2. Oktober 2017 16:58 To: Doerr, Martin > Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, >the floating point registers are mapped into VSR0-31. Hence, you can't use them for allocation in vectorx_reg. Thank you very much for your helpful comments. This is one of the points I did not understand on how to handle VSR even though there are duplication with FPR. I understand there is no trick and I need to use only VSR32-63 in this case. Updated webrev is : http://cr.openjdk.java.net/~mhorie/8188139/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for "Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into V]"Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for al From: "Doerr, Martin" > To: Michihiro Horie > Cc: "hotspot-dev at openjdk.java.net" > Date: 2017/10/02 18:47 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for allocation in vectorx_reg. Or how do you prevent the FP registers from getting killed? Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Michihiro Horie Sent: Samstag, 30. September 2017 17:22 To: Vladimir Kozlov > Cc: Simonis, Volker >; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Vladimir, Gustavo, Thanks a lot for your comments. I updated the webrev: http://cr.openjdk.java.net/~mhorie/8188139/webrev.01/ Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks,]Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks, From: Vladimir Kozlov > To: Gustavo Romero >, hotspot-dev at openjdk.java.net Cc: Michihiro Horie >, ppc-aix-port-dev at openjdk.java.net, "Simonis, Volker" > Date: 2017/09/30 06:40 Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ I am fine with it for these changes. Thanks, Vladimir On 9/29/17 12:19 PM, Gustavo Romero wrote: > Hi Vladimir, > > On 29-09-2017 16:00, Vladimir Kozlov wrote: >> I looked on shared code. One comment - change in opto/type.cpp affects s390. > > Do you strongly oppose to split PPC64 and s390 like? > > diff -r e93ed1a09240 src/share/vm/opto/type.cpp > --- a/src/share/vm/opto/type.cpp Tue Aug 08 22:57:34 2017 +0000 > +++ b/src/share/vm/opto/type.cpp Fri Sep 29 15:17:17 2017 -0400 > @@ -67,7 +67,13 @@ > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > -#elif defined(PPC64) || defined(S390) > +#elif defined(PPC64) > + { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > + { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > + { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX > + { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > + { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > +#elif defined(S390) > { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > > > Kind regards, > Gustavo > >> Vladimir >> >> On 9/29/17 2:37 AM, Michihiro Horie wrote: >>> Dear all, >>> >>> Would you please review the following change? >>> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8188139&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=8qV6XGFLseFXm282dspqVrhPluKMgjJ1JVqnM92Ttt4&e= >>> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8188139_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=hwk_4PJ5tU211eAdQ9txxjx_5WM9b6q4QXaZvsU98yI&e= >>> >>> This change introduces to use VSX for Superword Level Parallelization, concretely VSX instructions are emitted for Replicate[BSIFDL] nodes in ppc.ad. >>> Since I am not familiar with the hotspot's register allocation and the TOC use in POWER, I would be very grateful to have any comments to improve the change. >>> >>> In addition, the change includes some minor fixes in assembler_ppc.inline.hpp. I think there are some instructions that should have 1u in higher bits. >>> >>> >>> I used the attached micro benchmark. >>> /(See attached file: ArraysFillTest.java)/ >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: image001.gif URL: From HORIE at jp.ibm.com Wed Oct 4 10:13:58 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 4 Oct 2017 19:13:58 +0900 Subject: RFR(S):8188757:PPC64:Disable VSR52-63 in ppc.ad Message-ID: Dear all, Would you please review the following change in hs? Bug: https://bugs.openjdk.java.net/browse/JDK-8188757 Webrev: http://cr.openjdk.java.net/~mhorie/8188757/webrev.00/ This change disables VSR52-63 because currently there is no support for these registers to be properly treated as nonvolatile. Also, this change removes redundant logical or with 1u to enforce to use VSR32- registers in assembler_ppc.inline.hpp, which was done in my previous webrev for 8188139. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From HORIE at jp.ibm.com Wed Oct 4 10:18:10 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 4 Oct 2017 19:18:10 +0900 Subject: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX In-Reply-To: <1f107ecc19bc4602a983b047997d207c@sap.com> References: <1f107ecc19bc4602a983b047997d207c@sap.com> Message-ID: Hi Martin, I am very sorry for my careless mistakes on disabling VSR52-63. Yes, it is clear I should comment out them. I sent a new review request to fix this bug. http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-October/003212.html Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie , "ppc-aix-port-dev at openjdk.java.net" , "hotspot-dev at openjdk.java.net" Cc: Hiroshi H Horii , Gustavo Romero , Kazunori Ogata Date: 2017/10/04 16:46 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, unfortunately, an older version of your change was pushed. Can you create a new bug for your latest changes, please? Please note that the ?// nv!? does not help. These comments may help the reader but not the VM. You need to take them out and replace by a comment. (You can?t take the nv FP registers as a reference because they get saved and restored in the entry frame, so nv is only a comment there.) Thanks for contributing this change. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 04:27 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Hiroshi H Horii ; Doerr, Martin ; Gustavo Romero ; Kazunori Ogata Subject: Fw: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Dear all, I forward the mail exchanges with Martin to ppc-aix-port-dev. As I noted below, a latest webrev is following. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Forwarded by Michihiro Horie/Japan/IBM on 2017/10/04 11:23 ----- From: Michihiro Horie/Japan/IBM To: martin.doerr at sap.com Cc: hotspot-dev at openjdk.java.net Date: 2017/10/03 22:12 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX I noticed that vsra() etc. fill 1u in higher bits, sorry. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: Michihiro Horie/Japan/IBM To: "Doerr, Martin" Cc: "hotspot-dev at openjdk.java.net" Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Date: Tue, Oct 3, 2017 9:27 PM Hi Martin, Thank you very much for your further important comments. I understand VSR52-63 should not be used for now. Fixed webrev is: http://cr.openjdk.java.net/~mhorie/8188139/webrev.03/ Best regards, -- Michihiro, IBM Research - Tokyo "Doerr, Martin" ---2017/10/03 00:24:21---Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_ From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" Date: 2017/10/03 00:24 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_reg needs to be limited to the usable ones. (Comment should be fixed.) Unfortunately, the ABI specifies VR20-31 which map to VSR52-63 as nonvolatile. They could be used by the C code, but are not getting saved and restored. I guess it?s unlikely that there will be anything useful in these registers, but you never know what (future) compilers will do. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 2. Oktober 2017 16:58 To: Doerr, Martin Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, >the floating point registers are mapped into VSR0-31. Hence, you can?t use them for allocation in vectorx_reg. Thank you very much for your helpful comments. This is one of the points I did not understand on how to handle VSR even though there are duplication with FPR. I understand there is no trick and I need to use only VSR32-63 in this case. Updated webrev is : http://cr.openjdk.java.net/~mhorie/8188139/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into V"Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for al From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" Date: 2017/10/02 18:47 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can?t use them for allocation in vectorx_reg. Or how do you prevent the FP registers from getting killed? Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Michihiro Horie Sent: Samstag, 30. September 2017 17:22 To: Vladimir Kozlov Cc: Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Vladimir, Gustavo, Thanks a lot for your comments. I updated the webrev: http://cr.openjdk.java.net/~mhorie/8188139/webrev.01/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks,Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks, From: Vladimir Kozlov To: Gustavo Romero , hotspot-dev at openjdk.java.net Cc: Michihiro Horie , ppc-aix-port-dev at openjdk.java.net, "Simonis, Volker" Date: 2017/09/30 06:40 Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX I am fine with it for these changes. Thanks, Vladimir On 9/29/17 12:19 PM, Gustavo Romero wrote: > Hi Vladimir, > > On 29-09-2017 16:00, Vladimir Kozlov wrote: >> I looked on shared code. One comment - change in opto/type.cpp affects s390. > > Do you strongly oppose to split PPC64 and s390 like? > > diff -r e93ed1a09240 src/share/vm/opto/type.cpp > --- a/src/share/vm/opto/type.cpp Tue Aug 08 22:57:34 2017 +0000 > +++ b/src/share/vm/opto/type.cpp Fri Sep 29 15:17:17 2017 -0400 > @@ -67,7 +67,13 @@ > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > -#elif defined(PPC64) || defined(S390) > +#elif defined(PPC64) > + { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > + { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > + { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX > + { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > + { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > +#elif defined(S390) > { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > > > Kind regards, > Gustavo > >> Vladimir >> >> On 9/29/17 2:37 AM, Michihiro Horie wrote: >>> Dear all, >>> >>> Would you please review the following change? >>> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8188139&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=8qV6XGFLseFXm282dspqVrhPluKMgjJ1JVqnM92Ttt4&e= >>> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8188139_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=hwk_4PJ5tU211eAdQ9txxjx_5WM9b6q4QXaZvsU98yI&e= >>> >>> This change introduces to use VSX for Superword Level Parallelization, concretely VSX instructions are emitted for Replicate[BSIFDL] nodes in ppc.ad. >>> Since I am not familiar with the hotspot's register allocation and the TOC use in POWER, I would be very grateful to have any comments to improve the change. >>> >>> In addition, the change includes some minor fixes in assembler_ppc.inline.hpp. I think there are some instructions that should have 1u in higher bits. >>> >>> >>> I used the attached micro benchmark. >>> /(See attached file: ArraysFillTest.java)/ >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From jitendra.enania at in.ibm.com Wed Oct 4 10:35:40 2017 From: jitendra.enania at in.ibm.com (Jitendra Singh) Date: Wed, 4 Oct 2017 16:05:40 +0530 Subject: Query regarding support of OpenJDK 8 on linuxppc64le with RHEL 7.2 Message-ID: Hi, I would like to know whether OpenJDK 8 is tested/supported on linuxppc64le with RHEL 7.2 or not ? With Thanks and Regards, Jitendra Singh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Oct 4 12:05:49 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 4 Oct 2017 12:05:49 +0000 Subject: RFR(S):8188757:PPC64:Disable VSR52-63 in ppc.ad In-Reply-To: References: Message-ID: <47f7c8e22e364223b3f049998cf2506f@sap.com> Hi Michihiro, thanks for fixing it so quickly. Reviewed and pushed. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 12:14 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Doerr, Martin Cc: Simonis, Volker ; Hiroshi H Horii ; Kazunori Ogata ; Gustavo Romero Subject: RFR(S):8188757:PPC64:Disable VSR52-63 in ppc.ad Dear all, Would you please review the following change in hs? Bug: https://bugs.openjdk.java.net/browse/JDK-8188757 Webrev: http://cr.openjdk.java.net/~mhorie/8188757/webrev.00/ This change disables VSR52-63 because currently there is no support for these registers to be properly treated as nonvolatile. Also, this change removes redundant logical or with 1u to enforce to use VSR32- registers in assembler_ppc.inline.hpp, which was done in my previous webrev for 8188139. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Oct 4 12:56:37 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Oct 2017 12:56:37 +0000 Subject: Query regarding support of OpenJDK 8 on linuxppc64le with RHEL 7.2 In-Reply-To: References: Message-ID: <5cf7d7a602034afb846b73676b12c133@sap.com> Hi Jitendra, The team at SAP that contributed the ppc be port does not continuously build and test openJdk 8 on ppc64le. We do tests for be. We build be on SLES 11.3 with gcc 4.8.5, and do tests on various linux systems and Power Chips, currently SLES 11.0 and Fedora 19 on Power 7 and 8. But I would assume the port just works fine for your configuration, too. See also https://wiki.openjdk.java.net/pages/viewpage.action?pageId=25329853 Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Jitendra Singh > Sent: Mittwoch, 4. Oktober 2017 12:36 > To: ppc-aix-port-dev at openjdk.java.net > Subject: Query regarding support of OpenJDK 8 on linuxppc64le with RHEL 7.2 > > Hi, > > I would like to know whether OpenJDK 8 is tested/supported on linuxppc64le > with RHEL 7.2 or not ? > > With Thanks and Regards, > Jitendra Singh. From HORIE at jp.ibm.com Wed Oct 4 13:36:27 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 4 Oct 2017 22:36:27 +0900 Subject: RFR(S):8188757:PPC64:Disable VSR52-63 in ppc.ad In-Reply-To: <47f7c8e22e364223b3f049998cf2506f@sap.com> References: <47f7c8e22e364223b3f049998cf2506f@sap.com> Message-ID: Hi Martin, Thanks a lot for quickly reviewing and pushing the change. Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie , "ppc-aix-port-dev at openjdk.java.net" , "hotspot-dev at openjdk.java.net" Cc: "Simonis, Volker" , Hiroshi H Horii , Kazunori Ogata , Gustavo Romero Date: 2017/10/04 21:05 Subject: RE: RFR(S):8188757:PPC64:Disable VSR52-63 in ppc.ad Hi Michihiro, thanks for fixing it so quickly. Reviewed and pushed. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 12:14 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Doerr, Martin Cc: Simonis, Volker ; Hiroshi H Horii ; Kazunori Ogata ; Gustavo Romero Subject: RFR(S):8188757:PPC64:Disable VSR52-63 in ppc.ad Dear all, Would you please review the following change in hs? Bug: https://bugs.openjdk.java.net/browse/JDK-8188757 Webrev: http://cr.openjdk.java.net/~mhorie/8188757/webrev.00/ This change disables VSR52-63 because currently there is no support for these registers to be properly treated as nonvolatile. Also, this change removes redundant logical or with 1u to enforce to use VSR32- registers in assembler_ppc.inline.hpp, which was done in my previous webrev for 8188139. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From goetz.lindenmaier at sap.com Wed Oct 4 14:58:36 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Oct 2017 14:58:36 +0000 Subject: RFR(s): 8187547: PPC64: icache invalidation is incorrect in some places In-Reply-To: <5aac8f0a-b106-b7c7-8974-c4509c821d40@azul.com> References: <07b0d758-40eb-dc1f-e25b-49e031849744@azul.com> <1b20a156de344954a0ffe0bc88a07d6e@sap.com> <107e53d21d06483db1b01d0dd91c9cc9@sap.com> <5aac8f0a-b106-b7c7-8974-c4509c821d40@azul.com> Message-ID: <2b86eafec5d8404697be81a741c245a0@sap.com> HI Anton, I pushed the change the other day, but obviously I forgot to set you as author. Sorry for that. Feel free to account it to you by referencing this email. Best regards, Goetz > -----Original Message----- > From: Anton Kozlov [mailto:akozlov at azul.com] > Sent: Dienstag, 19. September 2017 13:44 > To: Lindenmaier, Goetz ; Doerr, Martin > ; ppc-aix-port-dev at openjdk.java.net; hotspot- > runtime-dev at openjdk.java.net > Subject: Re: RFR(s): 8187547: PPC64: icache invalidation is incorrect in some > places > > Hi, Goetz, > > thanks for rewiew! > > I made suggested changes in the patch and preparied webrev for jdk10- > master > > http://cr.openjdk.java.net/~akozlov/8187547/webrev.03/ > > > I assume you are allowed to contribute to openJdk being with Azul who > > have signed the OCA? > > Yes, Azul signed OCA and I'm working here. > > Thanks, > Anton > > On 15.09.2017 13:27, Lindenmaier, Goetz wrote: > > Hi Anton, > > > > thanks for fixing this issue. Looks good. > > > > Nevertheless I would find it more readable if the patch_* functions > > would just return the address of the first instruction. > > The code in nativeInst_ppc then would read > > > > if > (MacroAssembler::get_address_of_calculate_address_from_global_toc_at( > addr, cb->content_begin()) != > > (address)data) { > > address inst2_addr = addr; > > const address inst1_addr = > > > MacroAssembler::patch_calculate_address_from_global_toc_at(inst2_addr, > cb->content_begin(), > > (address)data); > > ICache::ppc64_flush_icache_bytes(inst1_addr, inst2_addr - inst1_addr + > BytesPerInstWord); > > } > > > > which I can read much more easily. > > Similar for patch_set_narrow_oop. > > You could add > > // Returns address of first instruction in sequence. > > in macroAssembler_ppc.hpp. > > > > Please update the Oracle copyright in nativeInst_ppc.cpp. > > > > Also, jdk10/master is available. Could you please prepare the webrev > against > > that repo? > > > > I assume you are allowed to contribute to openJdk being with Azul who > > have signed the OCA? > > > > Best regards, > > Goetz. > > > > > > > > > >> -----Original Message----- > >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > >> bounces at openjdk.java.net] On Behalf Of Anton Kozlov > >> Sent: Donnerstag, 14. September 2017 20:26 > >> To: Doerr, Martin ; ppc-aix-port- > >> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: RFR(s): 8187547: PPC64: icache invalidation is incorrect in > some > >> places > >> > >> Martin, > >> > >> thanks for review! > >> > >> I tried to keep knowledge of where relocation is pointing to in > >> macroAssembler. > >> But if simplier code is preferable, of course I'm agree with this. > >> > >> Webrev with suggestion applied: > >> http://cr.openjdk.java.net/~akozlov/8187547/webrev.02 > >> > >> I'm not very confident with the process for now (when repo closed), so > >> please do what should be done, I'll try to assist as much as I can. > >> > >> Backport should be easy, as the patch applies to jdk8u as well > >> > >> Thanks, > >> Anton > >> > >> On 14.09.2017 18:35, Doerr, Martin wrote: > >>> Hi Anton, > >>> > >>> thank you very much for providing a fix. Looks correct. > >>> > >>> In your current version, other_insn_offset is always negative. > >>> I'd prefer to make it always positive and simplify the usage like: > >>> assert(other_insn_offset > 0, "first instruction must be found"); > >>> start = addr - other_insn_offset; > >>> range = BytesPerInstWord + other_insn_offset; > >>> This would be better readable. Would you agree? > >>> > >>> At the moment, jdk10 repos are temporarily closed, but we can sponsor > >> the change when it's open again and after a 2nd review. > >>> Backports will also need to get addressed. > >>> > >>> Please note that ppc-aix-port-dev is not appropriate for reviews because > >> the PPC64 port is part of the main repos. Therefore, I've added hotspot- > >> runtime-dev. > >>> > >>> Best regards, > >>> Martin > >>> > >>> > >>> -----Original Message----- > >>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > >> bounces at openjdk.java.net] On Behalf Of Anton Kozlov > >>> Sent: Donnerstag, 14. September 2017 15:06 > >>> To: ppc-aix-port-dev at openjdk.java.net > >>> Subject: RFR(s): 8187547: PPC64: icache invalidation is incorrect in some > >> places > >>> > >>> Hi, All! > >>> > >>> Icache invalidation range calculation in > NativeMovConstReg::set_data_plain > >> and NativeMovConstReg::set_narrow_oop is incorrect and could cause > VM > >> crash: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8187547 > >>> > >>> I suppose the root is in mismatch of supposed and actual return values > of > >> MacroAssembler::patch_set_narrow_oop and > >> MacroAssembler::patch_calculate_address_from_global_toc_at. > >>> These functions takes address of the middle of sequence and expected > to > >> return first instruction offset (negative by current implementation). > Instead > >> of this, they return `-offset == abs(offset)` and offset to `data` > respectively. > >>> > >>> Supposed fix: http://cr.openjdk.java.net/~akozlov/8187547/webrev.01/ > >>> > >>> Thanks, > >>> Anton > >>> From martin.doerr at sap.com Wed Oct 4 17:14:51 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 4 Oct 2017 17:14:51 +0000 Subject: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX In-Reply-To: References: <1f107ecc19bc4602a983b047997d207c@sap.com> Message-ID: <625849dc299b4ec19d76cfc07bacbe65@sap.com> Hi Michihiro, the VM is broken on PPC64 after this change: assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) failed with repl4I_immIminus1. I guess the predicates are not good. Did you test debug build? We get the error pretty quickly when running jvm98 or simple tests like e.g. jtreg aes with -Xcomp. Regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 12:18 To: Doerr, Martin Cc: Gustavo Romero ; Hiroshi H Horii ; hotspot-dev at openjdk.java.net; Kazunori Ogata ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, I am very sorry for my careless mistakes on disabling VSR52-63. Yes, it is clear I should comment out them. I sent a new review request to fix this bug. http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-October/003212.html Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for "Doerr, Martin" ---2017/10/04 16:46:29---Hi Michihiro, unfortunately, an older version of your change]"Doerr, Martin" ---2017/10/04 16:46:29---Hi Michihiro, unfortunately, an older version of your change was pushed. Can you create a new bug fo From: "Doerr, Martin" > To: Michihiro Horie >, "ppc-aix-port-dev at openjdk.java.net" >, "hotspot-dev at openjdk.java.net" > Cc: Hiroshi H Horii >, Gustavo Romero >, Kazunori Ogata > Date: 2017/10/04 16:46 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ Hi Michihiro, unfortunately, an older version of your change was pushed. Can you create a new bug for your latest changes, please? Please note that the "// nv!" does not help. These comments may help the reader but not the VM. You need to take them out and replace by a comment. (You can't take the nv FP registers as a reference because they get saved and restored in the entry frame, so nv is only a comment there.) Thanks for contributing this change. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 04:27 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Hiroshi H Horii >; Doerr, Martin >; Gustavo Romero >; Kazunori Ogata > Subject: Fw: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Dear all, I forward the mail exchanges with Martin to ppc-aix-port-dev. As I noted below, a latest webrev is following. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Forwarded by Michihiro Horie/Japan/IBM on 2017/10/04 11:23 ----- From: Michihiro Horie/Japan/IBM To: martin.doerr at sap.com Cc: hotspot-dev at openjdk.java.net Date: 2017/10/03 22:12 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ I noticed that vsra() etc. fill 1u in higher bits, sorry. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: Michihiro Horie/Japan/IBM To: "Doerr, Martin" > Cc: "hotspot-dev at openjdk.java.net" > Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Date: Tue, Oct 3, 2017 9:27 PM Hi Martin, Thank you very much for your further important comments. I understand VSR52-63 should not be used for now. Fixed webrev is: http://cr.openjdk.java.net/~mhorie/8188139/webrev.03/ Best regards, -- Michihiro, IBM Research - Tokyo "Doerr, Martin" ---2017/10/03 00:24:21---Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_ From: "Doerr, Martin" > To: Michihiro Horie > Cc: "hotspot-dev at openjdk.java.net" > Date: 2017/10/03 00:24 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_reg needs to be limited to the usable ones. (Comment should be fixed.) Unfortunately, the ABI specifies VR20-31 which map to VSR52-63 as nonvolatile. They could be used by the C code, but are not getting saved and restored. I guess it's unlikely that there will be anything useful in these registers, but you never know what (future) compilers will do. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 2. Oktober 2017 16:58 To: Doerr, Martin > Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, >the floating point registers are mapped into VSR0-31. Hence, you can't use them for allocation in vectorx_reg. Thank you very much for your helpful comments. This is one of the points I did not understand on how to handle VSR even though there are duplication with FPR. I understand there is no trick and I need to use only VSR32-63 in this case. Updated webrev is : http://cr.openjdk.java.net/~mhorie/8188139/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for "Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into V]"Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for al From: "Doerr, Martin" > To: Michihiro Horie > Cc: "hotspot-dev at openjdk.java.net" > Date: 2017/10/02 18:47 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for allocation in vectorx_reg. Or how do you prevent the FP registers from getting killed? Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Michihiro Horie Sent: Samstag, 30. September 2017 17:22 To: Vladimir Kozlov > Cc: Simonis, Volker >; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Vladimir, Gustavo, Thanks a lot for your comments. I updated the webrev: http://cr.openjdk.java.net/~mhorie/8188139/webrev.01/ Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks,]Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks, From: Vladimir Kozlov > To: Gustavo Romero >, hotspot-dev at openjdk.java.net Cc: Michihiro Horie >, ppc-aix-port-dev at openjdk.java.net, "Simonis, Volker" > Date: 2017/09/30 06:40 Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX ________________________________ I am fine with it for these changes. Thanks, Vladimir On 9/29/17 12:19 PM, Gustavo Romero wrote: > Hi Vladimir, > > On 29-09-2017 16:00, Vladimir Kozlov wrote: >> I looked on shared code. One comment - change in opto/type.cpp affects s390. > > Do you strongly oppose to split PPC64 and s390 like? > > diff -r e93ed1a09240 src/share/vm/opto/type.cpp > --- a/src/share/vm/opto/type.cpp Tue Aug 08 22:57:34 2017 +0000 > +++ b/src/share/vm/opto/type.cpp Fri Sep 29 15:17:17 2017 -0400 > @@ -67,7 +67,13 @@ > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > -#elif defined(PPC64) || defined(S390) > +#elif defined(PPC64) > + { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > + { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > + { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX > + { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > + { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > +#elif defined(S390) > { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > > > Kind regards, > Gustavo > >> Vladimir >> >> On 9/29/17 2:37 AM, Michihiro Horie wrote: >>> Dear all, >>> >>> Would you please review the following change? >>> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8188139&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=8qV6XGFLseFXm282dspqVrhPluKMgjJ1JVqnM92Ttt4&e= >>> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8188139_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=hwk_4PJ5tU211eAdQ9txxjx_5WM9b6q4QXaZvsU98yI&e= >>> >>> This change introduces to use VSX for Superword Level Parallelization, concretely VSX instructions are emitted for Replicate[BSIFDL] nodes in ppc.ad. >>> Since I am not familiar with the hotspot's register allocation and the TOC use in POWER, I would be very grateful to have any comments to improve the change. >>> >>> In addition, the change includes some minor fixes in assembler_ppc.inline.hpp. I think there are some instructions that should have 1u in higher bits. >>> >>> >>> I used the attached micro benchmark. >>> /(See attached file: ArraysFillTest.java)/ >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: image001.gif URL: From HORIE at jp.ibm.com Thu Oct 5 09:15:55 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Thu, 5 Oct 2017 18:15:55 +0900 Subject: RFR:8188802:PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) Message-ID: Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8188802 Webrev: http://cr.openjdk.java.net/~mhorie/8188802/webrev.00/ This change fixes the assertion failures, which occur after introducing " 8188139:PPC64: Superword Level Parallelization with VSX". I exchanged the order of declarations of alloc_classes for SR and VSR. After this fix, another assertion in rc_class() in ppc.ad failed, I modified the assertion itself to take into account newly added VSRs. I would be happy to revise code if these changes do not make sense. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From HORIE at jp.ibm.com Thu Oct 5 09:19:56 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Thu, 5 Oct 2017 18:19:56 +0900 Subject: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX In-Reply-To: <625849dc299b4ec19d76cfc07bacbe65@sap.com> References: <1f107ecc19bc4602a983b047997d207c@sap.com> <625849dc299b4ec19d76cfc07bacbe65@sap.com> Message-ID: Hi Martin, Thank you very much for pointing out the problem. I posted a new bug and webrev to fix this failure. I would be very grateful if you would review this. http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-October/003220.html I am still thinking about your point on the predicates. I would be happy to revise code if current change is not sufficient. Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie Cc: Gustavo Romero , Hiroshi H Horii , "hotspot-dev at openjdk.java.net" , Kazunori Ogata , "ppc-aix-port-dev at openjdk.java.net" Date: 2017/10/05 02:16 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, the VM is broken on PPC64 after this change: assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) failed with repl4I_immIminus1. I guess the predicates are not good. Did you test debug build? We get the error pretty quickly when running jvm98 or simple tests like e.g. jtreg aes with -Xcomp. Regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 12:18 To: Doerr, Martin Cc: Gustavo Romero ; Hiroshi H Horii ; hotspot-dev at openjdk.java.net; Kazunori Ogata ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, I am very sorry for my careless mistakes on disabling VSR52-63. Yes, it is clear I should comment out them. I sent a new review request to fix this bug. http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-October/003212.html Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/10/04 16:46:29---Hi Michihiro, unfortunately, an older version of your change"Doerr, Martin" ---2017/10/04 16:46:29---Hi Michihiro, unfortunately, an older version of your change was pushed. Can you create a new bug fo From: "Doerr, Martin" To: Michihiro Horie , "ppc-aix-port-dev at openjdk.java.net" , "hotspot-dev at openjdk.java.net" < hotspot-dev at openjdk.java.net> Cc: Hiroshi H Horii , Gustavo Romero < gromero at linux.vnet.ibm.com>, Kazunori Ogata Date: 2017/10/04 16:46 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, unfortunately, an older version of your change was pushed. Can you create a new bug for your latest changes, please? Please note that the ?// nv!? does not help. These comments may help the reader but not the VM. You need to take them out and replace by a comment. (You can?t take the nv FP registers as a reference because they get saved and restored in the entry frame, so nv is only a comment there.) Thanks for contributing this change. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 4. Oktober 2017 04:27 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Hiroshi H Horii ; Doerr, Martin ; Gustavo Romero ; Kazunori Ogata < OGATAK at jp.ibm.com> Subject: Fw: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Dear all, I forward the mail exchanges with Martin to ppc-aix-port-dev. As I noted below, a latest webrev is following. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Forwarded by Michihiro Horie/Japan/IBM on 2017/10/04 11:23 ----- From: Michihiro Horie/Japan/IBM To: martin.doerr at sap.com Cc: hotspot-dev at openjdk.java.net Date: 2017/10/03 22:12 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX I noticed that vsra() etc. fill 1u in higher bits, sorry. http://cr.openjdk.java.net/~mhorie/8188139/webrev.04/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: Michihiro Horie/Japan/IBM To: "Doerr, Martin" Cc: "hotspot-dev at openjdk.java.net" Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Date: Tue, Oct 3, 2017 9:27 PM Hi Martin, Thank you very much for your further important comments. I understand VSR52-63 should not be used for now. Fixed webrev is: http://cr.openjdk.java.net/~mhorie/8188139/webrev.03/ Best regards, -- Michihiro, IBM Research - Tokyo "Doerr, Martin" ---2017/10/03 00:24:21---Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_ From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" Date: 2017/10/03 00:24 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, I think it was ok to list all VSR0-63 under Vector-Scalar Registers. Only the vectorx_reg needs to be limited to the usable ones. (Comment should be fixed.) Unfortunately, the ABI specifies VR20-31 which map to VSR52-63 as nonvolatile. They could be used by the C code, but are not getting saved and restored. I guess it?s unlikely that there will be anything useful in these registers, but you never know what (future) compilers will do. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 2. Oktober 2017 16:58 To: Doerr, Martin Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Martin, >the floating point registers are mapped into VSR0-31. Hence, you can?t use them for allocation in vectorx_reg. Thank you very much for your helpful comments. This is one of the points I did not understand on how to handle VSR even though there are duplication with FPR. I understand there is no trick and I need to use only VSR32-63 in this case. Updated webrev is : http://cr.openjdk.java.net/~mhorie/8188139/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into V"Doerr, Martin" ---2017/10/02 18:47:45---Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can't use them for al From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" Date: 2017/10/02 18:47 Subject: RE: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Hi Michihiro, the floating point registers are mapped into VSR0-31. Hence, you can?t use them for allocation in vectorx_reg. Or how do you prevent the FP registers from getting killed? Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Michihiro Horie Sent: Samstag, 30. September 2017 17:22 To: Vladimir Kozlov Cc: Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX Vladimir, Gustavo, Thanks a lot for your comments. I updated the webrev: http://cr.openjdk.java.net/~mhorie/8188139/webrev.01/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks,Vladimir Kozlov ---2017/09/30 06:40:45---I am fine with it for these changes. Thanks, From: Vladimir Kozlov To: Gustavo Romero , hotspot-dev at openjdk.java.net Cc: Michihiro Horie , ppc-aix-port-dev at openjdk.java.net, "Simonis, Volker" Date: 2017/09/30 06:40 Subject: Re: RFR(M):8188139:PPC64: Superword Level Parallelization with VSX I am fine with it for these changes. Thanks, Vladimir On 9/29/17 12:19 PM, Gustavo Romero wrote: > Hi Vladimir, > > On 29-09-2017 16:00, Vladimir Kozlov wrote: >> I looked on shared code. One comment - change in opto/type.cpp affects s390. > > Do you strongly oppose to split PPC64 and s390 like? > > diff -r e93ed1a09240 src/share/vm/opto/type.cpp > --- a/src/share/vm/opto/type.cpp Tue Aug 08 22:57:34 2017 +0000 > +++ b/src/share/vm/opto/type.cpp Fri Sep 29 15:17:17 2017 -0400 > @@ -67,7 +67,13 @@ > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > -#elif defined(PPC64) || defined(S390) > +#elif defined(PPC64) > + { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > + { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > + { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX > + { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY > + { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ > +#elif defined(S390) > { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS > { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD > { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX > > > Kind regards, > Gustavo > >> Vladimir >> >> On 9/29/17 2:37 AM, Michihiro Horie wrote: >>> Dear all, >>> >>> Would you please review the following change? >>> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8188139&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=8qV6XGFLseFXm282dspqVrhPluKMgjJ1JVqnM92Ttt4&e= >>> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8188139_webrev.00_&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=f45RKcOIfNDPttql5guPrieuHRGN_sCnNpTyDhdJQ5Q&s=hwk_4PJ5tU211eAdQ9txxjx_5WM9b6q4QXaZvsU98yI&e= >>> >>> This change introduces to use VSX for Superword Level Parallelization, concretely VSX instructions are emitted for Replicate[BSIFDL] nodes in ppc.ad. >>> Since I am not familiar with the hotspot's register allocation and the TOC use in POWER, I would be very grateful to have any comments to improve the change. >>> >>> In addition, the change includes some minor fixes in assembler_ppc.inline.hpp. I think there are some instructions that should have 1u in higher bits. >>> >>> >>> I used the attached micro benchmark. >>> /(See attached file: ArraysFillTest.java)/ >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From martin.doerr at sap.com Thu Oct 5 11:05:30 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 5 Oct 2017 11:05:30 +0000 Subject: RFR:8188802:PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) In-Reply-To: References: Message-ID: <058ad834758242c2a7bc9e39b1aa06df@sap.com> Hi Michihiro, pushed this change as it enables us to build and run the VM again. I have introduced a switch "SuperwordUseVSX" which I only enable on >=Power8. Reason is that you're using Power8 instructions which broke the VM for older processors. Regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Donnerstag, 5. Oktober 2017 11:16 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Doerr, Martin Cc: Hiroshi H Horii ; Gustavo Romero ; Kazunori Ogata Subject: RFR:8188802:PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8188802 Webrev: http://cr.openjdk.java.net/~mhorie/8188802/webrev.00/ This change fixes the assertion failures, which occur after introducing "8188139:PPC64: Superword Level Parallelization with VSX". I exchanged the order of declarations of alloc_classes for SR and VSR. After this fix, another assertion in rc_class() in ppc.ad failed, I modified the assertion itself to take into account newly added VSRs. I would be happy to revise code if these changes do not make sense. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From HORIE at jp.ibm.com Fri Oct 6 01:00:52 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Fri, 6 Oct 2017 10:00:52 +0900 Subject: RFR:8188802:PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) In-Reply-To: <058ad834758242c2a7bc9e39b1aa06df@sap.com> References: <058ad834758242c2a7bc9e39b1aa06df@sap.com> Message-ID: Hi Martin, Thanks a lot for fixing switches with "SuperwordUseVSX" and pushing the change. Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie , "ppc-aix-port-dev at openjdk.java.net" , "hotspot-dev at openjdk.java.net" Cc: Hiroshi H Horii , Gustavo Romero , Kazunori Ogata Date: 2017/10/05 20:05 Subject: RE: RFR:8188802:PPC64: Failure on assert (lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) Hi Michihiro, pushed this change as it enables us to build and run the VM again. I have introduced a switch ?SuperwordUseVSX? which I only enable on >=Power8. Reason is that you?re using Power8 instructions which broke the VM for older processors. Regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Donnerstag, 5. Oktober 2017 11:16 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Doerr, Martin Cc: Hiroshi H Horii ; Gustavo Romero ; Kazunori Ogata Subject: RFR:8188802:PPC64: Failure on assert(lrgmask.is_aligned_sets (RegMask::SlotsPerVecX)) Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8188802 Webrev: http://cr.openjdk.java.net/~mhorie/8188802/webrev.00/ This change fixes the assertion failures, which occur after introducing "8188139:PPC64: Superword Level Parallelization with VSX". I exchanged the order of declarations of alloc_classes for SR and VSR. After this fix, another assertion in rc_class() in ppc.ad failed, I modified the assertion itself to take into account newly added VSRs. I would be happy to revise code if these changes do not make sense. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From mbrandy at linux.vnet.ibm.com Thu Oct 12 16:16:16 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Thu, 12 Oct 2017 11:16:16 -0500 Subject: RFR(M) 8188165: PPC64: Optimize Unsafe.copyMemory and arraycopy In-Reply-To: References: Message-ID: [Ping] On 9/29/17 4:00 PM, Matthew Brandyberry wrote: > This is specific to PPC64LE only. > > The emphasis in the proposed code is on minimizing branches. Thus, > this code makes no attempt to avoid misaligned accesses and each block > is designed to copy as many elements as possible. > > As one data point, this yields as much as a 13x improvement in > jbyte_disjoint_arraycopy for certain misaligned scenarios. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188165 > Webrev: http://cr.openjdk.java.net/~mbrandy/8188165/jdk10/v1/ > > Thanks, > -Matt > From mbrandy at linux.vnet.ibm.com Thu Oct 12 16:17:12 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Thu, 12 Oct 2017 11:17:12 -0500 Subject: [8u] RFR (M) 8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: References: Message-ID: <1726202e-b051-6c46-73f8-2f2f5f01e418@linux.vnet.ibm.com> [Ping] On 9/28/17 12:53 PM, Matthew Brandyberry wrote: > Hi, > > Please review this backport of 8181809 for jdk8u. > > It applies cleanly to jdk8u except for the lack of C1 support on PPC > in 8u -- thus those changes are omitted here. > > This is a PPC-specific hotspot optimization that leverages the > mtfprd/mffprd instructions for for movement between general purpose > and floating point registers (rather than through memory). It yields a > ~35% improvement measured via a microbenchmark. > > webrev?????? :http://cr.openjdk.java.net/~mbrandy/8181809/jdk8u/v1 > > bug????????? :https://bugs.openjdk.java.net/browse/JDK-8181809 > > review > thread:http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-June/027226.html > > > Thank you. > -Matt > From thomas.stuefe at gmail.com Wed Oct 18 07:10:51 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 09:10:51 +0200 Subject: RFR(xxs): 8187230: [aix] Leave OS guard page size at default for non-java threads instead of explicitly setting it In-Reply-To: References: <368f252c8d5440e785e1ee341f4a918e@sap.com> Message-ID: Hi all, I am cleaning up my backlog of old issues which did not make it into the repo before the consolidation. Bug: https://bugs.openjdk.java.net/browse/JDK-8187230 Last Webrev (just rebased to the new repo structure, no changes): http://cr.openjdk.java.net/~stuefe/webrevs/8187230-aix-leave-os-guard-page-size-at-default-for-non-java-threads/webrev.02/webrev/ For your convenience, here the original message: <<< The change is very subtle. Before, we would set the OS guard page size for every thread - for java threads disable them, for non-java threads we'd set them to 4K. Now, we still disable them for java threads but leave them at the OS default size for non-java threads. The really important part is the disabling of OS guard pages for java threads, where we have a VM guard pages in place and do not want to spend more memory on OS guards. We do not really care for the exact size of the OS guard pages for non-java threads, and therefore should not set it - we should leave the size in place the OS deems sufficient. That also spares us the complexity of handling the thread stack page size, which on AIX may be different from os::vm_page_size(). >>> @Chris: you did ask whether this would make sense for Linux too. I think you are right, but as Goetz pointed out matters are more complicated as glibc pthread_create does not substract OS guard size from the user specified stack size, so it requires us to know the OS guard size and add it to the specified stack size (funny, the same issue we have with VM guards and -Xss). So, for now, I'd prefer this to keep AIX only. I think I need a second reviewer beside Goetz. Thanks! Thomas On Fri, Sep 8, 2017 at 10:48 AM, Thomas St?fe wrote: > Hi Guys, > > On Fri, Sep 8, 2017 at 9:51 AM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi Chris, >> >> on linux the pthread implementation is a bit strange, or buggy. >> It takes the OS guard pages out of the stack size specified. >> We need to set it so we can predict the additional space >> that must be allocated for the stack. >> >> See also the comment in os_linux.cpp, create_thread(). >> > > Goetz, I know we talked about this off list yesterday, but now I am not > sure this is actually needed. Yes, to correctly calculate the stack size, > we need to know the OS guard page size, but we do not need to set it, we > just need to know it. So, for non-java threads (java threads get the OS > guard set to zero), it would probably be sufficient to: > > - pthread_attr_init() (sets default thread attribute values to the > attribute structure) and then > - pthread_attr_getguardsize() to read the guard size from that structure. > > That way we leave the OS guard page at the size glibc deems best. I think > that is a better option. Consider a situation where the glibc changes the > size of the OS guard pages, for whatever reason - we probably should follow > suit. > > See e.g. this security issue - admittedly only loosely related, since the > fix for this issue seemed to be a fix to stack banging, not changing the OS > guard size: https://access.redhat.com/security/vulnerabilities/stackguard > > So, in short, I think we could change this for Linux too. If you guys > agree, I'll add this to the patch. Since I am on vacation and the depot is > closed, it may take some time. > > Kind Regards, Thomas > > > > > >> >> Best regards, >> Goetz. >> >> > -----Original Message----- >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounc >> es at openjdk.java.net] >> > On Behalf Of Chris Plummer >> > Sent: Thursday, September 07, 2017 11:07 PM >> > To: Thomas St?fe ; ppc-aix-port- >> > dev at openjdk.java.net >> > Cc: HotSpot Open Source Developers >> > Subject: Re: RFR(xxs): 8187230: [aix] Leave OS guard page size at >> default for >> > non-java threads instead of explicitly setting it >> > >> > Hi Thomas, >> > >> > Is there a reason this shouldn't also be done for linux? >> > >> > thanks, >> > >> > Chris >> > >> > On 9/7/17 3:02 AM, Thomas St?fe wrote: >> > > Hi all, >> > > >> > > may I please have a review for this small change: >> > > >> > > Bug: >> > > https://bugs.openjdk.java.net/browse/JDK-8187230 >> > > >> > > Webrev: >> > > http://cr.openjdk.java.net/~stuefe/webrevs/8187230-aix- >> > > leave-os-guard-page-size-at-default-for-non-java- >> > threads/webrev.00/webrev/ >> > > >> > > The change is very subtle. >> > > >> > > Before, we would set the OS guard page size for every thread - for >> java >> > > threads disable them, for non-java threads we'd set them to 4K. >> > > >> > > Now, we still disable them for java threads but leave them at the OS >> > > default size for non-java threads. >> > > >> > > The really important part is the disabling of OS guard pages for java >> > > threads, where we have a VM guard pages in place and do not want to >> > spend >> > > more memory on OS guards. We do not really care for the exact size of >> the >> > > OS guard pages for non-java threads, and therefore should not set it >> - we >> > > should leave the size in place the OS deems sufficient. That also >> spares us >> > > the complexity of handling the thread stack page size, which on AIX >> may be >> > > different from os::vm_page_size(). >> > > >> > > Thank you and Kind Regards, Thomas >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Oct 18 07:12:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Oct 2017 17:12:50 +1000 Subject: RFR(xxs): 8187230: [aix] Leave OS guard page size at default for non-java threads instead of explicitly setting it In-Reply-To: References: <368f252c8d5440e785e1ee341f4a918e@sap.com> Message-ID: Looks fine to me. Cheers, David On 18/10/2017 5:10 PM, Thomas St?fe wrote: > Hi all, > > I am cleaning up my backlog of old issues which did not make it into the > repo before the consolidation. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8187230 > > > Last Webrev (just rebased to the new repo structure, no changes): > http://cr.openjdk.java.net/~stuefe/webrevs/8187230-aix-leave-os-guard-page-size-at-default-for-non-java-threads/webrev.02/webrev/ > > For your convenience, here the original message: > > <<< > The change is very subtle. > > Before, we would set the OS guard page size for every thread - for java > threads disable them, for non-java threads we'd set them to 4K. > > Now, we still disable them for java threads but leave them at the OS > default size for non-java threads. > > The really important part is the disabling of OS guard pages for java > threads, where we have a VM guard pages in place and do not want to > spend more memory on OS guards. We do not really care for the exact size > of the OS guard pages for non-java threads, and therefore should not set > it - we should leave the size in place the OS deems sufficient. That > also spares us the complexity of handling the thread stack page size, > which on AIX may be different from os::vm_page_size(). > >>> > > @Chris: you did ask whether this would make sense for Linux too. I think > you are right, but as Goetz pointed out matters are more complicated as > glibc pthread_create does not substract OS guard size from the user > specified stack size, so it requires us to know the OS guard size and > add it to the specified stack size (funny, the same issue we have with > VM guards and -Xss). So, for now, I'd prefer this to keep AIX only. > > I think I need a second reviewer beside Goetz. > > Thanks! > > Thomas > > > > On Fri, Sep 8, 2017 at 10:48 AM, Thomas St?fe > wrote: > > Hi Guys, > > On Fri, Sep 8, 2017 at 9:51 AM, Lindenmaier, Goetz > > wrote: > > Hi Chris, > > on linux the pthread implementation is a bit strange, or buggy. > It takes the OS guard pages out of the stack size specified. > We need to set it so we can predict the additional space > that must be allocated for the stack. > > See also the comment in os_linux.cpp, create_thread(). > > > Goetz, I know we talked about this off list yesterday, but now I am > not sure this is actually needed. Yes, to correctly calculate the > stack size, we need to know the OS guard page size, but we do not > need to set it, we just need to know it. So, for non-java threads > (java threads get the OS guard set to zero), it would probably be > sufficient to: > > - pthread_attr_init() (sets default thread attribute values to the > attribute structure) and then > - pthread_attr_getguardsize() to read the guard size from that > structure. > > That way we leave the OS guard page at the size glibc deems best. I > think that is a better option. Consider a situation where the glibc > changes the size of the OS guard pages, for whatever reason - we > probably should follow suit. > > See e.g. this security issue - admittedly only loosely related, > since the fix for this issue seemed to be a fix to stack banging, > not changing the OS guard size: > https://access.redhat.com/security/vulnerabilities/stackguard > > > So, in short, I think we could change this for Linux too. If you > guys agree, I'll add this to the patch. Since I am on vacation and > the depot is closed, it may take some time. > > Kind Regards, Thomas > > > > > Best regards, > ? Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net > ] > > On Behalf Of Chris Plummer > > Sent: Thursday, September 07, 2017 11:07 PM > > To: Thomas St?fe >; > ppc-aix-port- > > dev at openjdk.java.net > > Cc: HotSpot Open Source Developers > > > Subject: Re: RFR(xxs): 8187230: [aix] Leave OS guard page size at default for > > non-java threads instead of explicitly setting it > > > > Hi Thomas, > > > > Is there a reason this shouldn't also be done for linux? > > > > thanks, > > > > Chris > > > > On 9/7/17 3:02 AM, Thomas St?fe wrote: > > > Hi all, > > > > > > may I please have a review for this small change: > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8187230 > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8187230-aix- > > > > leave-os-guard-page-size-at-default-for-non-java- > > threads/webrev.00/webrev/ > > > > > > The change is very subtle. > > > > > > Before, we would set the OS guard page size for every > thread - for java > > > threads disable them, for non-java threads we'd set them to 4K. > > > > > > Now, we still disable them for java threads but leave them > at the OS > > > default size for non-java threads. > > > > > > The really important part is the disabling of OS guard > pages for java > > > threads, where we have a VM guard pages in place and do not > want to > > spend > > > more memory on OS guards. We do not really care for the > exact size of the > > > OS guard pages for non-java threads, and therefore should > not set it - we > > > should leave the size in place the OS deems sufficient. > That also spares us > > > the complexity of handling the thread stack page size, > which on AIX may be > > > different from os::vm_page_size(). > > > > > > Thank you and Kind Regards, Thomas > > > > > > > From thomas.stuefe at gmail.com Wed Oct 18 07:27:24 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 09:27:24 +0200 Subject: RFR(xxs): 8187230: [aix] Leave OS guard page size at default for non-java threads instead of explicitly setting it In-Reply-To: References: <368f252c8d5440e785e1ee341f4a918e@sap.com> Message-ID: On Wed, Oct 18, 2017 at 9:12 AM, David Holmes wrote: > Looks fine to me. > > Cheers, > David > > Thanks David! > On 18/10/2017 5:10 PM, Thomas St?fe wrote: > >> Hi all, >> >> I am cleaning up my backlog of old issues which did not make it into the >> repo before the consolidation. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8187230 < >> https://bugs.openjdk.java.net/browse/JDK-8187230> >> >> Last Webrev (just rebased to the new repo structure, no changes): >> http://cr.openjdk.java.net/~stuefe/webrevs/8187230-aix-leave >> -os-guard-page-size-at-default-for-non-java-threads/webrev.02/webrev/ >> >> For your convenience, here the original message: >> >> <<< >> The change is very subtle. >> >> Before, we would set the OS guard page size for every thread - for java >> threads disable them, for non-java threads we'd set them to 4K. >> >> Now, we still disable them for java threads but leave them at the OS >> default size for non-java threads. >> >> The really important part is the disabling of OS guard pages for java >> threads, where we have a VM guard pages in place and do not want to spend >> more memory on OS guards. We do not really care for the exact size of the >> OS guard pages for non-java threads, and therefore should not set it - we >> should leave the size in place the OS deems sufficient. That also spares us >> the complexity of handling the thread stack page size, which on AIX may be >> different from os::vm_page_size(). >> >>> >> >> @Chris: you did ask whether this would make sense for Linux too. I think >> you are right, but as Goetz pointed out matters are more complicated as >> glibc pthread_create does not substract OS guard size from the user >> specified stack size, so it requires us to know the OS guard size and add >> it to the specified stack size (funny, the same issue we have with VM >> guards and -Xss). So, for now, I'd prefer this to keep AIX only. >> >> I think I need a second reviewer beside Goetz. >> >> Thanks! >> >> Thomas >> >> >> >> On Fri, Sep 8, 2017 at 10:48 AM, Thomas St?fe > > wrote: >> >> Hi Guys, >> >> On Fri, Sep 8, 2017 at 9:51 AM, Lindenmaier, Goetz >> > wrote: >> >> Hi Chris, >> >> on linux the pthread implementation is a bit strange, or buggy. >> It takes the OS guard pages out of the stack size specified. >> We need to set it so we can predict the additional space >> that must be allocated for the stack. >> >> See also the comment in os_linux.cpp, create_thread(). >> >> >> Goetz, I know we talked about this off list yesterday, but now I am >> not sure this is actually needed. Yes, to correctly calculate the >> stack size, we need to know the OS guard page size, but we do not >> need to set it, we just need to know it. So, for non-java threads >> (java threads get the OS guard set to zero), it would probably be >> sufficient to: >> >> - pthread_attr_init() (sets default thread attribute values to the >> attribute structure) and then >> - pthread_attr_getguardsize() to read the guard size from that >> structure. >> >> That way we leave the OS guard page at the size glibc deems best. I >> think that is a better option. Consider a situation where the glibc >> changes the size of the OS guard pages, for whatever reason - we >> probably should follow suit. >> >> See e.g. this security issue - admittedly only loosely related, >> since the fix for this issue seemed to be a fix to stack banging, >> not changing the OS guard size: >> https://access.redhat.com/security/vulnerabilities/stackguard >> >> >> So, in short, I think we could change this for Linux too. If you >> guys agree, I'll add this to the patch. Since I am on vacation and >> the depot is closed, it may take some time. >> >> Kind Regards, Thomas >> >> >> >> >> Best regards, >> Goetz. >> >> > -----Original Message----- >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounc >> es at openjdk.java.net >> ] >> > On Behalf Of Chris Plummer >> > Sent: Thursday, September 07, 2017 11:07 PM >> > To: Thomas St?fe > thomas.stuefe at gmail.com>>; >> ppc-aix-port- >> > dev at openjdk.java.net >> > Cc: HotSpot Open Source Developers < >> hotspot-dev at openjdk.java.net > >> > Subject: Re: RFR(xxs): 8187230: [aix] Leave OS guard page size >> at default for >> > non-java threads instead of explicitly setting it >> > >> > Hi Thomas, >> > >> > Is there a reason this shouldn't also be done for linux? >> > >> > thanks, >> > >> > Chris >> > >> > On 9/7/17 3:02 AM, Thomas St?fe wrote: >> > > Hi all, >> > > >> > > may I please have a review for this small change: >> > > >> > > Bug: >> > > https://bugs.openjdk.java.net/browse/JDK-8187230 >> >> > > >> > > Webrev: >> > > http://cr.openjdk.java.net/~stuefe/webrevs/8187230-aix- >> >> > > leave-os-guard-page-size-at-default-for-non-java- >> > threads/webrev.00/webrev/ >> > > >> > > The change is very subtle. >> > > >> > > Before, we would set the OS guard page size for every >> thread - for java >> > > threads disable them, for non-java threads we'd set them to >> 4K. >> > > >> > > Now, we still disable them for java threads but leave them >> at the OS >> > > default size for non-java threads. >> > > >> > > The really important part is the disabling of OS guard >> pages for java >> > > threads, where we have a VM guard pages in place and do not >> want to >> > spend >> > > more memory on OS guards. We do not really care for the >> exact size of the >> > > OS guard pages for non-java threads, and therefore should >> not set it - we >> > > should leave the size in place the OS deems sufficient. >> That also spares us >> > > the complexity of handling the thread stack page size, >> which on AIX may be >> > > different from os::vm_page_size(). >> > > >> > > Thank you and Kind Regards, Thomas >> > >> > >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Oct 18 07:44:54 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 09:44:54 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> Message-ID: 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 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/ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Oct 18 08:14:40 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 18 Oct 2017 10:14:40 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> Message-ID: Hi Thomas, Shouldn't the following line: ? 47???? return len2 + pagesize - 1 / pagesize; ..be written as: ??? ??? ?? return (len2 + pagesize - 1) / pagesize; Regards, Peter On 10/18/2017 09:44 AM, Thomas St?fe wrote: > 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-overflow-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 > 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-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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Oct 18 08:17:29 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 18 Oct 2017 10:17:29 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> Message-ID: On 10/18/2017 10:14 AM, Peter Levart wrote: > Hi Thomas, > > Shouldn't the following line: > > ? 47???? return len2 + pagesize - 1 / pagesize; > > ..be written as: > > ??? ??? ?? return (len2 + pagesize - 1) / pagesize; ...or better yet, as: ??? ??? ?????? return numPages; (you already calculate it correctly in previous line, but then return an expression, which is wrong). Regards, Peter > > > Regards, Peter > > On 10/18/2017 09:44 AM, Thomas St?fe wrote: >> 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-overflow-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 >> > 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-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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Oct 18 08:23:42 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Oct 2017 08:23:42 +0000 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> Message-ID: Hi Thomas, apart from the point that Peter found, I?d also think it would look better if the typedef section (line 51-56) would be placed before the AIX only function (line 41-49). Other than that, it looks good to me. Best regards Christoph From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Peter Levart Sent: Mittwoch, 18. Oktober 2017 10:17 To: Thomas St?fe ; Alan Bateman Cc: nio-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Java Core Libs Subject: Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 On 10/18/2017 10:14 AM, Peter Levart wrote: Hi Thomas, Shouldn't the following line: 47 return len2 + pagesize - 1 / pagesize; ..be written as: return (len2 + pagesize - 1) / pagesize; ...or better yet, as: return numPages; (you already calculate it correctly in previous line, but then return an expression, which is wrong). Regards, Peter Regards, Peter On 10/18/2017 09:44 AM, Thomas St?fe wrote: 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-overflow-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 > 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-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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Oct 18 08:32:39 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 18 Oct 2017 10:32:39 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> Message-ID: <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> Hi Thomas, Just one more concern... On 10/18/2017 09:44 AM, Thomas St?fe wrote: > 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-overflow-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... If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps also the MappedByteBuffer.load() method is wrong for AIX? ??? public final MappedByteBuffer load() { ??????? checkMapped(); ??????? if ((address == 0) || (capacity() == 0)) ??????????? return this; ??????? long offset = mappingOffset(); ??????? long length = mappingLength(offset); ??????? load0(mappingAddress(offset), length); ??????? // Read a byte from each page to bring it into memory. A checksum ??????? // is computed as we go along to prevent the compiler from otherwise ??????? // considering the loop as dead code. ??????? Unsafe unsafe = Unsafe.getUnsafe(); ??????? int ps = Bits.pageSize(); // << LOOK HERE ??????? int count = Bits.pageCount(length); ??????? long a = mappingAddress(offset); ??????? byte x = 0; ??????? for (int i=0; i > 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 > 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-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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Oct 18 10:00:36 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 12:00:36 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: References: Message-ID: Hi Goetz, Eric, I was unable to commit this patch before the jdk10 repo consolidation and would like to do so now. Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data-segment-page-size-64K-by-default/webrev.01/webrev/ Nothing changed, the webrev is just rebased to the new repo. I am unclear whether I am allowed to push this on my own? Does the build group this? Kind Regards, Thomas On Thu, Sep 7, 2017 at 2:33 PM, Thomas St?fe wrote: > Thank you Goetz! > > On Thu, Sep 7, 2017 at 2:18 PM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi Thomas, >> >> Looks good. >> >> Best regards, >> Goetz. >> >> > -----Original Message----- >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> > bounces at openjdk.java.net] On Behalf Of Thomas St?fe >> > Sent: Donnerstag, 7. September 2017 12:02 >> > To: ppc-aix-port-dev at openjdk.java.net; build-dev > > dev at openjdk.java.net> >> > Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by >> default >> > >> > 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/ >> > > > 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Oct 18 10:02:39 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Oct 2017 10:02:39 +0000 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: References: Message-ID: Hi Thomas, someone from Oracle must push this as they need to regenerate the generated_configure.sh file. So you need a sponsor. Best regards, Goetz. > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Mittwoch, 18. Oktober 2017 12:01 > To: Lindenmaier, Goetz ; Erik Joelsson > > Cc: ppc-aix-port-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: Re: RFR(xs): 8187228: [aix] make data segment page size 64K by > default > > Hi Goetz, Eric, > > I was unable to commit this patch before the jdk10 repo consolidation and > would like to do so now. > > Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make- > data-segment-page-size-64K-by-default/webrev.01/webrev/ > > Nothing changed, the webrev is just rebased to the new repo. > > I am unclear whether I am allowed to push this on my own? Does the build > group this? > > Kind Regards, Thomas > > > On Thu, Sep 7, 2017 at 2:33 PM, Thomas St?fe > wrote: > > > Thank you Goetz! > > On Thu, Sep 7, 2017 at 2:18 PM, Lindenmaier, Goetz > > > wrote: > > > Hi Thomas, > > Looks good. > > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net > ] On Behalf Of Thomas St?fe > > Sent: Donnerstag, 7. September 2017 12:02 > > To: ppc-aix-port-dev at openjdk.java.net port-dev at openjdk.java.net> ; build-dev > dev at openjdk.java.net > > > Subject: RFR(xs): 8187228: [aix] make data segment page > size 64K by default > > > > 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- > segment-> > > page-size-64K-by-default/webrev.00/webrev/ > > make-data- 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 > > > From thomas.stuefe at gmail.com Wed Oct 18 10:24:11 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 12:24:11 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> Message-ID: Hi Peter, Christoph, Thank you both for reviewing. New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/ @Peter: >Shouldn't the following line: > > 47 return len2 + pagesize - 1 / pagesize; > >..be written as: > > return (len2 + pagesize - 1) / pagesize; You are right. Did not cause the mincore output buffer to be unnecessarily large. Thanks for catching this. As for your other concern: On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart wrote: > -- > 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... > > > If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps > also the MappedByteBuffer.load() method is wrong for AIX? > > public final MappedByteBuffer load() { > checkMapped(); > if ((address == 0) || (capacity() == 0)) > return this; > long offset = mappingOffset(); > long length = mappingLength(offset); > load0(mappingAddress(offset), length); > > // Read a byte from each page to bring it into memory. A checksum > // is computed as we go along to prevent the compiler from > otherwise > // considering the loop as dead code. > Unsafe unsafe = Unsafe.getUnsafe(); > int ps = Bits.pageSize(); // << LOOK HERE > int count = Bits.pageCount(length); > long a = mappingAddress(offset); > byte x = 0; > for (int i=0; i x ^= unsafe.getByte(a); > a += ps; // << AND HERE > } > if (unused != 0) > unused = x; > > return this; > } > > ...this loop reads a byte from the start of each block in lumps of > Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather > need a special Unsafe.mmappedPageSize() method instead of just a hack in > isLoaded0 ? > > Yes, I considered this too. In effect, on AIX, we only touch every 16th page, thereby reducing MappedByteBuffer::load() to something like load_every_16th_page... However, this bug is very old (even our 1.4 VM already does this when the touching was still implemented in MappedByteBuffer.c) and did not cause any problems AFAIK. The story behind this is long and quite boring :) basically, 64k pages are used for the java heap and give a large performance bonus over 4K paged java heap. But we cannot switch all memory regions to 64K pages, so we live with multiple page sizes and above us we have a ton of code which assumes one consistent page size for everything. So we lie about the page size to everyone - claiming system page size to be 64k - and except for very rare cases like this one get away with this. I would like to keep lying consistently. There is not a hard reason for it, just that I am afraid that starting to publish a different page size to parts of the VM will confuse things and may introduce errors further down the line. I think a proper solution would be to keep page size on a per-ByteBuffer base, because ByteBuffers may be allocated in different memory regions - they are now allocated with mmap() in system page size, but that may change in the future. That is assuming that one byte buffer cannot span areas of multiple page sizes, which would complicate matters further. Btw, I also wondered whether other platforms could have a clash between the real memory page size and MappedByteBuffer's notion of that size - e.g. whether it is possible to have MappedByteBuffers with huge pages on Linux. But all cases I could think of are cases where the page size the JDK would assume is smaller than the actual page size, which would not be a problem for both mincore and load/touch. In the above example (huge pages on Linux), pages would be pinned anyway, so load() and isLoaded() would be noops. @Christoph: > apart from the point that Peter found, I?d also think it would look better if the typedef section (line 51-56) would be placed before the AIX only function (line 41-49). Sure. I moved the section up, below the includes. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Oct 18 10:43:37 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 18 Oct 2017 10:43:37 +0000 Subject: 8188131: [PPC] Increase inlining thresholds to the same as other platforms In-Reply-To: References: Message-ID: <6a5027ffe1c14f48a0bf39523c88aa4b@sap.com> 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://bugs.openjdk.java.net/browse/JDK-8188131 Webrev: http://cr.openjdk.java.net/~horii/8188131/webrev.00/ 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 From erik.joelsson at oracle.com Wed Oct 18 11:29:02 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Oct 2017 13:29:02 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: References: Message-ID: <25871ad0-201c-07ca-123f-3c03b719a692@oracle.com> I can sponsor the change. /Erik On 2017-10-18 12:00, Thomas St?fe wrote: > Hi Goetz, Eric, > > I was unable to commit this patch before the jdk10 repo consolidation > and would like to do so now. > > Last Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data-segment-page-size-64K-by-default/webrev.01/webrev/ > > > Nothing changed, the webrev is just rebased to the new repo. > > I am unclear whether I am allowed to push this on my own? Does the > build group this? > > Kind Regards, Thomas > > > On Thu, Sep 7, 2017 at 2:33 PM, Thomas St?fe > wrote: > > Thank you Goetz! > > On Thu, Sep 7, 2017 at 2:18 PM, Lindenmaier, Goetz > > wrote: > > Hi Thomas, > > Looks good. > > Best regards, > ? Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net ] > On Behalf Of Thomas St?fe > > Sent: Donnerstag, 7. September 2017 12:02 > > To: ppc-aix-port-dev at openjdk.java.net > ; build-dev > dev at openjdk.java.net > > > Subject: RFR(xs): 8187228: [aix] make data segment page size > 64K by default > > > > 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/ > > > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Oct 18 11:40:17 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Oct 2017 11:40:17 +0000 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Wed Oct 18 12:34:21 2017 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 18 Oct 2017 12:34:21 +0000 Subject: AIX build not generating a jre image Message-ID: 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Oct 18 12:56:01 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Oct 2017 12:56:01 +0000 Subject: AIX build not generating a jre image In-Reply-To: References: Message-ID: <3c093f8a812f4b879a180de987f70e1c@sap.com> 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 at openjdk.java.net] On Behalf Of Steve Groeger > Sent: Mittwoch, 18. Oktober 2017 14:34 > To: ppc-aix-port-dev at 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 at 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 From erik.joelsson at oracle.com Wed Oct 18 12:57:28 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Oct 2017 14:57:28 +0200 Subject: AIX build not generating a jre image In-Reply-To: <3c093f8a812f4b879a180de987f70e1c@sap.com> References: <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: <1c7e2bc3-2ebb-2e93-13d3-62d9e1645527@oracle.com> Hello Steve, What do your configure and make commands look like? /Erik On 2017-10-18 14:56, Lindenmaier, Goetz wrote: > 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 at openjdk.java.net] On Behalf Of Steve Groeger >> Sent: Mittwoch, 18. Oktober 2017 14:34 >> To: ppc-aix-port-dev at 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 at 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 From thomas.stuefe at gmail.com Wed Oct 18 13:22:54 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 15:22:54 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: <25871ad0-201c-07ca-123f-3c03b719a692@oracle.com> References: <25871ad0-201c-07ca-123f-3c03b719a692@oracle.com> Message-ID: Thank you Eric! On Wed, Oct 18, 2017 at 1:29 PM, Erik Joelsson wrote: > I can sponsor the change. > > /Erik > > On 2017-10-18 12:00, Thomas St?fe wrote: > > Hi Goetz, Eric, > > I was unable to commit this patch before the jdk10 repo consolidation and > would like to do so now. > > Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8187228-make-data-segment-page-size-64K-by-default/webrev.01/webrev/ > > Nothing changed, the webrev is just rebased to the new repo. > > I am unclear whether I am allowed to push this on my own? Does the build > group this? > > Kind Regards, Thomas > > > On Thu, Sep 7, 2017 at 2:33 PM, Thomas St?fe > wrote: > >> Thank you Goetz! >> >> On Thu, Sep 7, 2017 at 2:18 PM, Lindenmaier, Goetz < >> goetz.lindenmaier at sap.com> wrote: >> >>> Hi Thomas, >>> >>> Looks good. >>> >>> Best regards, >>> Goetz. >>> >>> > -----Original Message----- >>> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >>> > bounces at openjdk.java.net] On Behalf Of Thomas St?fe >>> > Sent: Donnerstag, 7. September 2017 12:02 >>> > To: ppc-aix-port-dev at openjdk.java.net; build-dev >> > dev at openjdk.java.net> >>> > Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by >>> default >>> > >>> > 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/ >>> > >> > 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 >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Oct 18 13:25:58 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Oct 2017 13:25:58 +0000 Subject: AIX build not generating a jre image In-Reply-To: <3c093f8a812f4b879a180de987f70e1c@sap.com> References: <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: Hi Goetz, How do our nightly builds look like? Do they create the JRE image? Regards, Volker Lindenmaier, Goetz 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 at openjdk.java.net] On Behalf Of Steve Groeger > > Sent: Mittwoch, 18. Oktober 2017 14:34 > > To: ppc-aix-port-dev at 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 at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Oct 18 14:14:12 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 16:14:12 +0200 Subject: AIX build not generating a jre image In-Reply-To: References: <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis 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 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 at openjdk.java.net] On Behalf Of Steve Groeger > > > Sent: Mittwoch, 18. Oktober 2017 14:34 > > > To: ppc-aix-port-dev at 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 at 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Wed Oct 18 15:17:37 2017 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 18 Oct 2017 15:17:37 +0000 Subject: AIX build not generating a jre image In-Reply-To: References: , <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: 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 at 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 wrote: ----- To: Volker Simonis From: Thomas St?fe Date: 10/18/2017 15:14 Cc: "Lindenmaier, Goetz" , Steve Groeger , "build-dev (build-dev at openjdk.java.net)" , "ppc-aix-port-dev at openjdk.java.net" Subject: Re: AIX build not generating a jre image On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis 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 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 at openjdk.java.net] On Behalf Of Steve Groeger > > Sent: Mittwoch, 18. Oktober 2017 14:34 > > To: ppc-aix-port-dev at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Oct 18 15:45:31 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Oct 2017 17:45:31 +0200 Subject: 8189619: [aix, but changes generated-configure.sh] OpenJDK local disk check not working on AIX Message-ID: 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-broken-on-aix/webrev.00/webrev/ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From OGATAK at jp.ibm.com Thu Oct 19 06:43:19 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 19 Oct 2017 15:43:19 +0900 Subject: 8188131: [PPC] Increase inlining thresholds to the same as other platforms In-Reply-To: References: Message-ID: 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" To: Kazunori Ogata , "hotspot-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_n7vS453MD73lAZxkNhGsrlDkk-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_n7vS453MD73lAZxkNhGsrlDkk-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 From goetz.lindenmaier at sap.com Thu Oct 19 11:03:16 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Oct 2017 11:03:16 +0000 Subject: 8188131: [PPC] Increase inlining thresholds to the same as other platforms In-Reply-To: References: Message-ID: 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 > 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" > To: Kazunori Ogata , "hotspot- > 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 > > > From thomas.stuefe at gmail.com Thu Oct 19 13:21:58 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Oct 2017 15:21:58 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> Message-ID: Hi Peter, Christoph, if you have no objections, I'd like to push this change. As I explained in my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if you are fine with the change in its current form (http://cr.openjdk. java.net/~stuefe/webrevs/8186665-buffer-overflow-in- mincore/webrev.02/webrev/), I'd like to push it. Thanks, Thomas On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe wrote: > Hi Peter, Christoph, > > Thank you both for reviewing. > > New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8186665-buffer-overflow-in-mincore/webrev.02/webrev/ > > @Peter: > > >Shouldn't the following line: > > > > 47 return len2 + pagesize - 1 / pagesize; > > > >..be written as: > > > > return (len2 + pagesize - 1) / pagesize; > > You are right. Did not cause the mincore output buffer to be unnecessarily > large. Thanks for catching this. > > As for your other concern: > > > On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart > wrote: > >> -- >> 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... >> >> >> If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps >> also the MappedByteBuffer.load() method is wrong for AIX? >> >> public final MappedByteBuffer load() { >> checkMapped(); >> if ((address == 0) || (capacity() == 0)) >> return this; >> long offset = mappingOffset(); >> long length = mappingLength(offset); >> load0(mappingAddress(offset), length); >> >> // Read a byte from each page to bring it into memory. A checksum >> // is computed as we go along to prevent the compiler from >> otherwise >> // considering the loop as dead code. >> Unsafe unsafe = Unsafe.getUnsafe(); >> int ps = Bits.pageSize(); // << LOOK HERE >> int count = Bits.pageCount(length); >> long a = mappingAddress(offset); >> byte x = 0; >> for (int i=0; i> x ^= unsafe.getByte(a); >> a += ps; // << AND HERE >> } >> if (unused != 0) >> unused = x; >> >> return this; >> } >> >> ...this loop reads a byte from the start of each block in lumps of >> Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather >> need a special Unsafe.mmappedPageSize() method instead of just a hack in >> isLoaded0 ? >> >> > Yes, I considered this too. In effect, on AIX, we only touch every 16th > page, thereby reducing MappedByteBuffer::load() to something like > load_every_16th_page... However, this bug is very old (even our 1.4 VM > already does this when the touching was still implemented in > MappedByteBuffer.c) and did not cause any problems AFAIK. > > The story behind this is long and quite boring :) basically, 64k pages are > used for the java heap and give a large performance bonus over 4K paged > java heap. But we cannot switch all memory regions to 64K pages, so we live > with multiple page sizes and above us we have a ton of code which assumes > one consistent page size for everything. So we lie about the page size to > everyone - claiming system page size to be 64k - and except for very rare > cases like this one get away with this. > > I would like to keep lying consistently. There is not a hard reason for > it, just that I am afraid that starting to publish a different page size to > parts of the VM will confuse things and may introduce errors further down > the line. > > I think a proper solution would be to keep page size on a per-ByteBuffer > base, because ByteBuffers may be allocated in different memory regions - > they are now allocated with mmap() in system page size, but that may change > in the future. That is assuming that one byte buffer cannot span areas of > multiple page sizes, which would complicate matters further. > > Btw, I also wondered whether other platforms could have a clash between > the real memory page size and MappedByteBuffer's notion of that size - e.g. > whether it is possible to have MappedByteBuffers with huge pages on Linux. > But all cases I could think of are cases where the page size the JDK would > assume is smaller than the actual page size, which would not be a problem > for both mincore and load/touch. In the above example (huge pages on > Linux), pages would be pinned anyway, so load() and isLoaded() would be > noops. > > > @Christoph: > > > apart from the point that Peter found, I?d also think it would look > better if the typedef section (line 51-56) would be placed before the AIX > only function (line 41-49). > > > Sure. I moved the section up, below the includes. > > Kind Regards, Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Oct 19 13:22:45 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Oct 2017 13:22:45 +0000 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> Message-ID: <99e9d160c1df4129969421931f08ff24@sap.com> Hi Thomas, ok from my end. Best regards Christoph From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Donnerstag, 19. Oktober 2017 15:22 To: Peter Levart ; Langer, Christoph Cc: Alan Bateman ; nio-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Java Core Libs Subject: Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 Hi Peter, Christoph, if you have no objections, I'd like to push this change. As I explained in my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if you are fine with the change in its current form (http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/), I'd like to push it. Thanks, Thomas On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe > wrote: Hi Peter, Christoph, Thank you both for reviewing. New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/ @Peter: >Shouldn't the following line: > > 47 return len2 + pagesize - 1 / pagesize; > >..be written as: > > return (len2 + pagesize - 1) / pagesize; You are right. Did not cause the mincore output buffer to be unnecessarily large. Thanks for catching this. As for your other concern: On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart > wrote: -- 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... If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps also the MappedByteBuffer.load() method is wrong for AIX? public final MappedByteBuffer load() { checkMapped(); if ((address == 0) || (capacity() == 0)) return this; long offset = mappingOffset(); long length = mappingLength(offset); load0(mappingAddress(offset), length); // Read a byte from each page to bring it into memory. A checksum // is computed as we go along to prevent the compiler from otherwise // considering the loop as dead code. Unsafe unsafe = Unsafe.getUnsafe(); int ps = Bits.pageSize(); // << LOOK HERE int count = Bits.pageCount(length); long a = mappingAddress(offset); byte x = 0; for (int i=0; i apart from the point that Peter found, I?d also think it would look better if the typedef section (line 51-56) would be placed before the AIX only function (line 41-49). Sure. I moved the section up, below the includes. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Oct 19 13:29:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Oct 2017 15:29:03 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: <99e9d160c1df4129969421931f08ff24@sap.com> References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> <99e9d160c1df4129969421931f08ff24@sap.com> Message-ID: Thanks Christoph! On Thu, Oct 19, 2017 at 3:22 PM, Langer, Christoph wrote: > Hi Thomas, > > > > ok from my end. > > > > Best regards > > Christoph > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Donnerstag, 19. Oktober 2017 15:22 > *To:* Peter Levart ; Langer, Christoph < > christoph.langer at sap.com> > *Cc:* Alan Bateman ; nio-dev at openjdk.java.net; > ppc-aix-port-dev at openjdk.java.net; Java Core Libs < > core-libs-dev at openjdk.java.net> > *Subject:* Re: RFR(xs): (aix but affects shared code too) 8186665: buffer > overflow in Java_java_nio_MappedByteBuffer_isLoaded0 > > > > Hi Peter, Christoph, > > > > if you have no objections, I'd like to push this change. As I explained in > my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if > you are fine with the change in its current form ( > http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer- > overflow-in-mincore/webrev.02/webrev/), I'd like to push it. > > > > Thanks, Thomas > > > > > > On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe > wrote: > > Hi Peter, Christoph, > > > > Thank you both for reviewing. > > > > New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8186665-buffer-overflow-in-mincore/webrev.02/webrev/ > > > > @Peter: > > > > >Shouldn't the following line: > > > > 47 return len2 + pagesize - 1 / pagesize; > > > >..be written as: > > > > return (len2 + pagesize - 1) / pagesize; > > > > You are right. Did not cause the mincore output buffer to be unnecessarily > large. Thanks for catching this. > > > > As for your other concern: > > > > > > On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart > wrote: > > -- > 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... > > > If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps > also the MappedByteBuffer.load() method is wrong for AIX? > > public final MappedByteBuffer load() { > checkMapped(); > if ((address == 0) || (capacity() == 0)) > return this; > long offset = mappingOffset(); > long length = mappingLength(offset); > load0(mappingAddress(offset), length); > > // Read a byte from each page to bring it into memory. A checksum > // is computed as we go along to prevent the compiler from > otherwise > // considering the loop as dead code. > Unsafe unsafe = Unsafe.getUnsafe(); > int ps = Bits.pageSize(); // << LOOK HERE > int count = Bits.pageCount(length); > long a = mappingAddress(offset); > byte x = 0; > for (int i=0; i x ^= unsafe.getByte(a); > a += ps; // << AND HERE > } > if (unused != 0) > unused = x; > > return this; > } > > ...this loop reads a byte from the start of each block in lumps of > Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather > need a special Unsafe.mmappedPageSize() method instead of just a hack in > isLoaded0 ? > > > > Yes, I considered this too. In effect, on AIX, we only touch every 16th > page, thereby reducing MappedByteBuffer::load() to something like > load_every_16th_page... However, this bug is very old (even our 1.4 VM > already does this when the touching was still implemented in > MappedByteBuffer.c) and did not cause any problems AFAIK. > > > > The story behind this is long and quite boring :) basically, 64k pages are > used for the java heap and give a large performance bonus over 4K paged > java heap. But we cannot switch all memory regions to 64K pages, so we live > with multiple page sizes and above us we have a ton of code which assumes > one consistent page size for everything. So we lie about the page size to > everyone - claiming system page size to be 64k - and except for very rare > cases like this one get away with this. > > > > I would like to keep lying consistently. There is not a hard reason for > it, just that I am afraid that starting to publish a different page size to > parts of the VM will confuse things and may introduce errors further down > the line. > > > > I think a proper solution would be to keep page size on a per-ByteBuffer > base, because ByteBuffers may be allocated in different memory regions - > they are now allocated with mmap() in system page size, but that may change > in the future. That is assuming that one byte buffer cannot span areas of > multiple page sizes, which would complicate matters further. > > > > Btw, I also wondered whether other platforms could have a clash between > the real memory page size and MappedByteBuffer's notion of that size - e.g. > whether it is possible to have MappedByteBuffers with huge pages on Linux. > But all cases I could think of are cases where the page size the JDK would > assume is smaller than the actual page size, which would not be a problem > for both mincore and load/touch. In the above example (huge pages on > Linux), pages would be pinned anyway, so load() and isLoaded() would be > noops. > > > > > > @Christoph: > > > > > apart from the point that Peter found, I?d also think it would look > better if the typedef section (line 51-56) would be placed before the AIX > only function (line 41-49). > > > > Sure. I moved the section up, below the includes. > > > > Kind Regards, Thomas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Thu Oct 19 20:42:19 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 19 Oct 2017 22:42:19 +0200 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> Message-ID: <746b8bb2-0203-f50c-c7bd-77e5a0e434f7@gmail.com> Hi Thomas, Right. I can understand the situation and potential problems of introducing API for mmappedPageSize. So let's keep pretending that page size is uniform for all memory regions used by VM and see where this brings us. The change fixes the problem, although in a hack-ish way. It will be good for now. Regards, Peter On 10/19/17 15:21, Thomas St?fe wrote: > Hi Peter, Christoph, > > if you have no objections, I'd like to push this change. As I > explained in my earlier mail, I'd prefer not to change > MappedByteBuffer::load(), and if you are fine with the change in its > current form > (http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/ > ), > I'd like to push it. > > Thanks, Thomas > > > On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe > > wrote: > > Hi Peter, Christoph, > > Thank you both for reviewing. > > New webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/ > > > @Peter: > > >Shouldn't the following line: > > > >? 47???? return len2 + pagesize - 1 / pagesize; > > > >..be written as: > > > >? ? ? ? ? ?return (len2 + pagesize - 1) / pagesize; > > You are right. Did not cause the mincore output buffer to be > unnecessarily large. Thanks for catching this. > > As for your other concern: > > > On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart > > wrote: > >> -- >> 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... > > If this is true and Unsafe.pagesize() returns a value > 4K, > then perhaps also the MappedByteBuffer.load() method is wrong > for AIX? > > ??? public final MappedByteBuffer load() { > ??????? checkMapped(); > ??????? if ((address == 0) || (capacity() == 0)) > ??????????? return this; > ??????? long offset = mappingOffset(); > ??????? long length = mappingLength(offset); > ??????? load0(mappingAddress(offset), length); > > ??????? // Read a byte from each page to bring it into memory. > A checksum > ??????? // is computed as we go along to prevent the compiler > from otherwise > ??????? // considering the loop as dead code. > ??????? Unsafe unsafe = Unsafe.getUnsafe(); > ??????? int ps = Bits.pageSize(); // << LOOK HERE > ??????? int count = Bits.pageCount(length); > ??????? long a = mappingAddress(offset); > ??????? byte x = 0; > ??????? for (int i=0; i ??????????? x ^= unsafe.getByte(a); > ??????????? a += ps; // << AND HERE > ??????? } > ??????? if (unused != 0) > ??????????? unused = x; > > ??????? return this; > ??? } > > ...this loop reads a byte from the start of each block in > lumps of Bits.pageSize(). Should it always read in lumps of 4K > for AIX? Do we rather need a special Unsafe.mmappedPageSize() > method instead of just a hack in isLoaded0 ? > > > Yes, I considered this too. In effect, on AIX, we only touch every > 16th page, thereby reducing MappedByteBuffer::load() to something > like load_every_16th_page... However, this bug is very old (even > our 1.4 VM already does this when the touching was still > implemented in MappedByteBuffer.c) and did not cause any problems > AFAIK. > > The story behind this is long and quite boring :) basically, 64k > pages are used for the java heap and give a large performance > bonus over 4K paged java heap. But we cannot switch all memory > regions to 64K pages, so we live with multiple page sizes and > above us we have a ton of code which assumes one consistent page > size for everything. So we lie about the page size to everyone - > claiming system page size to be 64k - and except for very rare > cases like this one get away with this. > > I would like to keep lying consistently. There is not a hard > reason for it, just that I am afraid that starting to publish a > different page size to parts of the VM will confuse things and may > introduce errors further down the line. > > I think a proper solution would be to keep page size on a > per-ByteBuffer base, because ByteBuffers may be allocated in > different memory regions - they are now allocated with mmap() in > system page size, but that may change in the future. That is > assuming that one byte buffer cannot span areas of multiple page > sizes, which would complicate matters further. > > Btw, I also wondered whether other platforms could have a clash > between the real memory page size and MappedByteBuffer's notion of > that size - e.g. whether it is possible to have MappedByteBuffers > with huge pages on Linux. But all cases I could think of?are cases > where the page size the JDK would assume is smaller than the > actual page size, which would not be a problem for both mincore > and load/touch. In the above example (huge pages on Linux), pages > would be pinned anyway, so load() and isLoaded() would be noops. > > > @Christoph: > > > apart from the point that Peter found, I?d also think it would > look better if the typedef section (line 51-56) would be placed > before the AIX only function (line 41-49). > > > Sure. I moved the section up, below the includes. > > Kind Regards, Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Oct 19 20:43:24 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Oct 2017 20:43:24 +0000 Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0 In-Reply-To: <746b8bb2-0203-f50c-c7bd-77e5a0e434f7@gmail.com> References: <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com> <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com> <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com> <746b8bb2-0203-f50c-c7bd-77e5a0e434f7@gmail.com> Message-ID: Thank you, Peter. ..Thomas On Thu 19. Oct 2017 at 22:42, Peter Levart wrote: > Hi Thomas, > > Right. I can understand the situation and potential problems of > introducing API for mmappedPageSize. So let's keep pretending that page > size is uniform for all memory regions used by VM and see where this brings > us. The change fixes the problem, although in a hack-ish way. It will be > good for now. > > Regards, Peter > > > > On 10/19/17 15:21, Thomas St?fe wrote: > > Hi Peter, Christoph, > > if you have no objections, I'd like to push this change. As I explained in > my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if > you are fine with the change in its current form ( > http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/), > I'd like to push it. > > Thanks, Thomas > > > On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe > wrote: > >> Hi Peter, Christoph, >> >> Thank you both for reviewing. >> >> New webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/ >> >> @Peter: >> >> >Shouldn't the following line: >> > >> > 47 return len2 + pagesize - 1 / pagesize; >> > >> >..be written as: >> > >> > return (len2 + pagesize - 1) / pagesize; >> >> You are right. Did not cause the mincore output buffer to be >> unnecessarily large. Thanks for catching this. >> >> As for your other concern: >> >> >> On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart >> wrote: >> >>> -- >>> 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... >>> >>> >>> If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps >>> also the MappedByteBuffer.load() method is wrong for AIX? >>> >>> public final MappedByteBuffer load() { >>> checkMapped(); >>> if ((address == 0) || (capacity() == 0)) >>> return this; >>> long offset = mappingOffset(); >>> long length = mappingLength(offset); >>> load0(mappingAddress(offset), length); >>> >>> // Read a byte from each page to bring it into memory. A checksum >>> // is computed as we go along to prevent the compiler from >>> otherwise >>> // considering the loop as dead code. >>> Unsafe unsafe = Unsafe.getUnsafe(); >>> int ps = Bits.pageSize(); // << LOOK HERE >>> int count = Bits.pageCount(length); >>> long a = mappingAddress(offset); >>> byte x = 0; >>> for (int i=0; i>> x ^= unsafe.getByte(a); >>> a += ps; // << AND HERE >>> } >>> if (unused != 0) >>> unused = x; >>> >>> return this; >>> } >>> >>> ...this loop reads a byte from the start of each block in lumps of >>> Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather >>> need a special Unsafe.mmappedPageSize() method instead of just a hack in >>> isLoaded0 ? >>> >>> >> Yes, I considered this too. In effect, on AIX, we only touch every 16th >> page, thereby reducing MappedByteBuffer::load() to something like >> load_every_16th_page... However, this bug is very old (even our 1.4 VM >> already does this when the touching was still implemented in >> MappedByteBuffer.c) and did not cause any problems AFAIK. >> >> The story behind this is long and quite boring :) basically, 64k pages >> are used for the java heap and give a large performance bonus over 4K paged >> java heap. But we cannot switch all memory regions to 64K pages, so we live >> with multiple page sizes and above us we have a ton of code which assumes >> one consistent page size for everything. So we lie about the page size to >> everyone - claiming system page size to be 64k - and except for very rare >> cases like this one get away with this. >> >> I would like to keep lying consistently. There is not a hard reason for >> it, just that I am afraid that starting to publish a different page size to >> parts of the VM will confuse things and may introduce errors further down >> the line. >> >> I think a proper solution would be to keep page size on a per-ByteBuffer >> base, because ByteBuffers may be allocated in different memory regions - >> they are now allocated with mmap() in system page size, but that may change >> in the future. That is assuming that one byte buffer cannot span areas of >> multiple page sizes, which would complicate matters further. >> >> Btw, I also wondered whether other platforms could have a clash between >> the real memory page size and MappedByteBuffer's notion of that size - e.g. >> whether it is possible to have MappedByteBuffers with huge pages on Linux. >> But all cases I could think of are cases where the page size the JDK would >> assume is smaller than the actual page size, which would not be a problem >> for both mincore and load/touch. In the above example (huge pages on >> Linux), pages would be pinned anyway, so load() and isLoaded() would be >> noops. >> >> >> @Christoph: >> >> > apart from the point that Peter found, I?d also think it would look >> better if the typedef section (line 51-56) would be placed before the AIX >> only function (line 41-49). >> >> >> Sure. I moved the section up, below the includes. >> >> Kind Regards, Thomas >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From OGATAK at jp.ibm.com Fri Oct 20 06:31:47 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 20 Oct 2017 15:31:47 +0900 Subject: 8188131: [PPC] Increase inlining thresholds to the same as other platforms In-Reply-To: References: Message-ID: 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" To: Kazunori Ogata , "Doerr, Martin" Cc: "ppc-aix-port-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 > 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" > To: Kazunori Ogata , "hotspot- > 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 > > > From thomas.stuefe at gmail.com Fri Oct 20 08:28:11 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 20 Oct 2017 10:28:11 +0200 Subject: 8189619: [aix, but changes generated-configure.sh] OpenJDK local disk check not working on AIX In-Reply-To: References: Message-ID: Hi guys, if you have time, could I please have a review, this is really quite minor. I tested the resulting configure.sh on AIX, various Linuxes and Windows. Thank you! ..Thomas On Wed, Oct 18, 2017 at 5:45 PM, Thomas St?fe wrote: > 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-broken-on-aix/webrev.00/webrev/ > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Oct 20 08:50:01 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Oct 2017 10:50:01 +0200 Subject: 8189619: [aix, but changes generated-configure.sh] OpenJDK local disk check not working on AIX In-Reply-To: References: Message-ID: <58314d8a-a9bc-1041-512d-5e61d9e610b6@oracle.com> Hello Thomas, This looks good and I can sponsor it. /Erik On 2017-10-20 10:28, Thomas St?fe wrote: > Hi guys, > > if you have time, could I please have a review, this is really quite minor. > I tested the resulting configure.sh on AIX, various Linuxes and Windows. > > Thank you! > > ..Thomas > > On Wed, Oct 18, 2017 at 5:45 PM, Thomas St?fe > wrote: > >> 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-broken-on-aix/webrev.00/webrev/ >> >> 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 >> >> From thomas.stuefe at gmail.com Fri Oct 20 10:48:05 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 20 Oct 2017 12:48:05 +0200 Subject: 8189619: [aix, but changes generated-configure.sh] OpenJDK local disk check not working on AIX In-Reply-To: <58314d8a-a9bc-1041-512d-5e61d9e610b6@oracle.com> References: <58314d8a-a9bc-1041-512d-5e61d9e610b6@oracle.com> Message-ID: Thank you Eric! On Fri, Oct 20, 2017 at 10:50 AM, Erik Joelsson wrote: > Hello Thomas, > > This looks good and I can sponsor it. > > /Erik > > > > On 2017-10-20 10:28, Thomas St?fe wrote: > >> Hi guys, >> >> if you have time, could I please have a review, this is really quite >> minor. >> I tested the resulting configure.sh on AIX, various Linuxes and Windows. >> >> Thank you! >> >> ..Thomas >> >> On Wed, Oct 18, 2017 at 5:45 PM, Thomas St?fe >> wrote: >> >> 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-broken-on-aix/webrev.00/webrev/ >>> >>> 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 >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raduandritoiu at gmail.com Wed Oct 18 12:20:54 2017 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Wed, 18 Oct 2017 15:20:54 +0300 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: Message-ID: 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. My question is if the final VM will have support for JNI, because I will need to run a java project that is already coded and uses JNI generated by SWIG. Also thank you for the help and info about Azul. Thank you, Radu On Wed, Oct 18, 2017 at 2:40 PM, Volker Simonis wrote: > 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 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Mon Oct 23 07:12:45 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 23 Oct 2017 09:12:45 +0200 Subject: AIX build not generating a jre image In-Reply-To: References: <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: On 2017-10-18 16:14, Thomas St?fe wrote: > On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > 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. Since I don't have access to any AIX machines, it's difficult to for me to do much about this. Let me know if you need assistance in tracking this down. Some suggestions: run "make LOG=info,cmdlines" to track the progress of the build. If you get lost in the log files, try running "make jre-image" and then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines jre-image" to see only the output for the jre-image target. /Magnus > > I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. > > ..Thomas > > > > >> Lindenmaier, Goetz 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 at openjdk.java.net] On Behalf Of Steve Groeger >>>> Sent: Mittwoch, 18. Oktober 2017 14:34 >>>> To: ppc-aix-port-dev at 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 at 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 >>> From thomas.stuefe at gmail.com Mon Oct 23 08:16:40 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 23 Oct 2017 10:16:40 +0200 Subject: AIX build not generating a jre image In-Reply-To: References: <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: Hi Magnus, On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2017-10-18 16:14, Thomas St?fe wrote: > >> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > > >> 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. >> > Since I don't have access to any AIX machines, it's difficult to for me to > do much about this. Let me know if you need assistance in tracking this > down. > > Some suggestions: > run "make LOG=info,cmdlines" to track the progress of the build. > > If you get lost in the log files, try running "make jre-image" and then > "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines jre-image" > to see only the output for the jre-image target. > > Thanks for the hints! I'll try that. I played around last week with make -d --print-data-base but got lost in the information. Last week I burned some time on this problem without much success. I got stuck understanding the rule in Images.gmk: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) $(ECHO) Creating jre jimage $(RM) -r $(JRE_IMAGE_DIR) $(JLINK_JRE_EXTRA_OPTS) \ $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ --output $(JRE_IMAGE_DIR) $(TOUCH) $@ and its brethren. It seems this rule just does not get executed for jre-image. So, trying to understand this (I am no makefile expert): $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target dir, in this case jre/java, whose non-existence or out-of-dateness triggers the rule Dependencies: - $(JMODS) is /jmods, which gets built and does exist - $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) I have trouble understanding this. $(BASE_RELEASE_FILE) is a text file which, if it exists and it contains the value of $JRE_MODULES_LIST, will result false (not out of date), otherwise it will update the file with the value of $JRE_MODULES_LIST and return true, triggering the target, yes? If I got this right, why do we use the same output file for all targets (jre, jdk) etc? ..Thomas > /Magnus > > > > >> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. >> >> ..Thomas >> >> >> >> >> Lindenmaier, Goetz 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 at openjdk.java.net] On Behalf Of Steve Groeger >>>>> Sent: Mittwoch, 18. Oktober 2017 14:34 >>>>> To: ppc-aix-port-dev at 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 at 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 >>>>> >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Oct 24 07:24:43 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Oct 2017 07:24:43 +0000 Subject: 8188131: [PPC] Increase inlining thresholds to the same as other platforms In-Reply-To: References: Message-ID: <374596dc72ed4b54bd9e3cc43e221d72@sap.com> 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 at jp.ibm.com] > Sent: Freitag, 20. Oktober 2017 08:32 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; Doerr, Martin ; > ppc-aix-port-dev at 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" > To: Kazunori Ogata , "Doerr, Martin" > > Cc: "ppc-aix-port-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 > > 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" > > To: Kazunori Ogata , "hotspot- > > 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 > > > > > > > > > From raduandritoiu at gmail.com Tue Oct 24 09:00:47 2017 From: raduandritoiu at gmail.com (Radu Andritoiu) Date: Tue, 24 Oct 2017 12:00:47 +0300 Subject: Cross compile jdk8u on PPC32 In-Reply-To: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: 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 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. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Tue Oct 24 09:08:42 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 24 Oct 2017 09:08:42 +0000 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: <5f61da5183944c5eb8c3e3d870ffea64@sap.com> Hi Radu, 'hotspot/src/cpu/ppc' only supports PPC64. I?m not so familiar with the zero build, but I?ve heard about people using zero on PPC32 (e.g. for Debian). Maybe one of them can provide hints. Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Radu Andritoiu Sent: Dienstag, 24. Oktober 2017 11:01 To: Andrew Haley Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Ivan Krylov Subject: Re: Cross compile jdk8u on PPC32 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 > 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. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Oct 24 09:11:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Oct 2017 19:11:35 +1000 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: On 24/10/2017 7:00 PM, Radu Andritoiu wrote: > 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'? You don't "use" a specific folder the build takes care of that for you. When you build zero it uses src/cpu/zero. > Do I try to build/compile using jvm-variant 'zero' and force it to use the > code from 'hotspot/src/cpu/ppc'? No. > Is the source-code from 'hotspot/src/cpu/ppc' onlu for PPC 64? Yes. David > > Thank you very much for the help, > Radu > > > > On Tue, Oct 24, 2017 at 11:46 AM, Andrew Haley 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. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> From thomas.stuefe at gmail.com Tue Oct 24 09:19:33 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Oct 2017 11:19:33 +0200 Subject: Cross compile jdk8u on PPC32 In-Reply-To: References: Message-ID: Hi Radu, On Wed, Oct 18, 2017 at 2:20 PM, 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. > > My question is if the final VM will have support for JNI, because I will > need to run a java project that is already coded and uses JNI generated by > SWIG. > > To answer that question, yes, it will support JNI. Zero and JNA both use the libffi, but beside that have nothing to do with each other. One is a configuration option for the hotspot VM, the other is a library independent of OpenJDK. Best Regards,Thomas > Also thank you for the help and info about Azul. > > Thank you, > Radu > > > On Wed, Oct 18, 2017 at 2:40 PM, Volker Simonis > wrote: > >> 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 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/jniTyp >>> es_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 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From OGATAK at jp.ibm.com Tue Oct 24 11:11:53 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 24 Oct 2017 20:11:53 +0900 Subject: 8188131: [PPC] Increase inlining thresholds to the same as other platforms In-Reply-To: References: Message-ID: 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" To: Kazunori Ogata , "'hotspot-compiler-dev at openjdk.java.net'" Cc: "Doerr, Martin" , "ppc-aix-port-dev at 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 at jp.ibm.com] > Sent: Freitag, 20. Oktober 2017 08:32 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; Doerr, Martin ; > ppc-aix-port-dev at 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" > To: Kazunori Ogata , "Doerr, Martin" > > Cc: "ppc-aix-port-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 > > 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" > > To: Kazunori Ogata , "hotspot- > > 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 > > > > > > > > > From bob.vandette at oracle.com Tue Oct 24 12:34:14 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 24 Oct 2017 08:34:14 -0400 Subject: Cross compile jdk8u on PPC32 In-Reply-To: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> References: <9b00b55d-7683-ce7f-dff0-f162347e94f4@redhat.com> Message-ID: As others have mentioned, you need to target ZERO and not PPC32 when trying to build a non supported cpu architecture with the Zero interpreter. You do need to have a libffi.so binary available for the build. Zero uses this to manage the native stack frames. Bob. > On Oct 24, 2017, at 4:46 AM, Andrew Haley 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. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Tue Oct 24 13:46:36 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Oct 2017 15:46:36 +0200 Subject: AIX build not generating a jre image In-Reply-To: References: <3c093f8a812f4b879a180de987f70e1c@sap.com> Message-ID: <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> On 2017-10-23 10:16, Thomas St?fe wrote: > Hi Magnus, > > On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > > > wrote: > > > On 2017-10-18 16:14, Thomas St?fe wrote: > > On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > > > 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. > > Since I don't have access to any AIX machines, it's difficult to > for me to do much about this. Let me know if you need assistance > in tracking this down. > > Some suggestions: > run "make LOG=info,cmdlines" to track the progress of the build. > > If you get lost in the log files, try running "make jre-image" and > then "rm build/$BUILD/images/jre", and then "make > LOG=info,cmdlines jre-image" to see only the output for the > jre-image target. > > > Thanks for the hints! I'll try that. I played around last week with > make -d --print-data-base but got lost in the information. > > Last week I burned some time on this problem without much success. I > got stuck understanding the rule in Images.gmk: > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > ? ? $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > $(ECHO) Creating jre jimage > $(RM) -r $(JRE_IMAGE_DIR) > ? ?$(JLINK_JRE_EXTRA_OPTS) \ > $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > ? ?--output $(JRE_IMAGE_DIR) > $(TOUCH) $@ > > and its brethren. > > It seems this rule just does not get executed for jre-image. So, > trying to understand this (I am no makefile expert): > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target > dir, in this case jre/java, whose non-existence or out-of-dateness > triggers the rule > > Dependencies: > ?- $(JMODS) is /jmods, which gets built and does exist > ?- $(call DependOnVariable, JRE_MODULES_LIST) This is just a macro that creates a dependency on the contents of the variable JRE_MODULES_LIST. > $(BASE_RELEASE_FILE) is a text file which, if it exists and it > contains the value of $JRE_MODULES_LIST, will result false (not out of > date), otherwise it will update the file with the value of > $JRE_MODULES_LIST and return true, triggering the target, yes? If I > got this right, why do we use the same output file for all targets > (jre, jdk) etc? No, this is a separate dependency. It's the file named "release" in the image that is to be included. If it has changed we need to trigger a new image. Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? If not, there's a problem before we even get to this rule. Otherwise, the jlink command is likely broken. Try copy-pasting the full jlink command and running it from the shell directly to see what happens. /Magnus > > ..Thomas > > > /Magnus > > > > > I created https://bugs.openjdk.java.net/browse/JDK-8189618 > to track this. > > ..Thomas > > > > > Lindenmaier, Goetz > 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 at openjdk.java.net > ] On Behalf Of > Steve Groeger > Sent: Mittwoch, 18. Oktober 2017 14:34 > To: ppc-aix-port-dev at 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 at 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Tue Oct 24 14:44:53 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 24 Oct 2017 14:44:53 +0000 Subject: AIX build not generating a jre image In-Reply-To: <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> References: <3c093f8a812f4b879a180de987f70e1c@sap.com> <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> Message-ID: * Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? Hi Magnus, when comparing the linux and aix logs of our openjdk9 builds , I see for Linux at some point : gmake[3]: Entering directory ` . . . /nightly/jdk9/make' /bin/echo Creating jre jimage While on AIX it says : make[3]: Entering directory ` . . . /nightly/jdk9/make' make[3]: Nothing to be done for `jre'. make[3]: Leaving directory ` . . . /nightly/jdk9/make' this Looks wrong to me ! ( the . . . in the output has been removed by me it points to the build dir). Best regards, Matthias From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie Sent: Dienstag, 24. Oktober 2017 15:47 To: Thomas St?fe Cc: build-dev (build-dev at openjdk.java.net) ; ppc-aix-port-dev at openjdk.java.net Subject: Re: AIX build not generating a jre image On 2017-10-23 10:16, Thomas St?fe wrote: Hi Magnus, On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > wrote: On 2017-10-18 16:14, Thomas St?fe wrote: On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > 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. Since I don't have access to any AIX machines, it's difficult to for me to do much about this. Let me know if you need assistance in tracking this down. Some suggestions: run "make LOG=info,cmdlines" to track the progress of the build. If you get lost in the log files, try running "make jre-image" and then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines jre-image" to see only the output for the jre-image target. Thanks for the hints! I'll try that. I played around last week with make -d --print-data-base but got lost in the information. Last week I burned some time on this problem without much success. I got stuck understanding the rule in Images.gmk: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) $(ECHO) Creating jre jimage $(RM) -r $(JRE_IMAGE_DIR) $(JLINK_JRE_EXTRA_OPTS) \ $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ --output $(JRE_IMAGE_DIR) $(TOUCH) $@ and its brethren. It seems this rule just does not get executed for jre-image. So, trying to understand this (I am no makefile expert): $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target dir, in this case jre/java, whose non-existence or out-of-dateness triggers the rule Dependencies: - $(JMODS) is /jmods, which gets built and does exist - $(call DependOnVariable, JRE_MODULES_LIST) This is just a macro that creates a dependency on the contents of the variable JRE_MODULES_LIST. $(BASE_RELEASE_FILE) is a text file which, if it exists and it contains the value of $JRE_MODULES_LIST, will result false (not out of date), otherwise it will update the file with the value of $JRE_MODULES_LIST and return true, triggering the target, yes? If I got this right, why do we use the same output file for all targets (jre, jdk) etc? No, this is a separate dependency. It's the file named "release" in the image that is to be included. If it has changed we need to trigger a new image. Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? If not, there's a problem before we even get to this rule. Otherwise, the jlink command is likely broken. Try copy-pasting the full jlink command and running it from the shell directly to see what happens. /Magnus ..Thomas /Magnus I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. ..Thomas Lindenmaier, Goetz > 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 at openjdk.java.net] On Behalf Of Steve Groeger Sent: Mittwoch, 18. Oktober 2017 14:34 To: ppc-aix-port-dev at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Oct 25 08:24:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Oct 2017 10:24:23 +0200 Subject: AIX build not generating a jre image In-Reply-To: References: <3c093f8a812f4b879a180de987f70e1c@sap.com> <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> Message-ID: On 2017-10-24 16:44, Baesken, Matthias wrote: > > * Do you get to this stage at all? I.e, can you see "Createing jre > jimage" in the output? > > Hi Magnus, when comparing the linux and aix logs? of our openjdk9 > builds? , ??I see for Linux at some point : > > gmake[3]: Entering directory ` . . . /nightly/jdk9/make' > /bin/echo Creating jre jimage > > While on AIX it says : > > make[3]: Entering directory ` . . . /nightly/jdk9/make' > make[3]: Nothing to be done for `jre'. > make[3]: Leaving directory ` . . . /nightly/jdk9/make' > > this Looks wrong to me ! > That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is considered up to date by make. This is wrong if that file does not exist. Are you *sure* you do not have a jre built? Verify the contents of these variables. Perhaps add a $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) at the top of Images.gmk, and check the location that is printed. /Magnus > (? the? ?. . .?? in the output has been removed by me it points to the > build dir). > > Best regards, Matthias > > *From:*ppc-aix-port-dev > [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] *On Behalf Of > *Magnus Ihse Bursie > *Sent:* Dienstag, 24. Oktober 2017 15:47 > *To:* Thomas St?fe > *Cc:* build-dev (build-dev at openjdk.java.net) > ; ppc-aix-port-dev at openjdk.java.net > *Subject:* Re: AIX build not generating a jre image > > On 2017-10-23 10:16, Thomas St?fe wrote: > > Hi Magnus, > > On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > > wrote: > > > On 2017-10-18 16:14, Thomas St?fe wrote: > > On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > > > 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. > > Since I don't have access to any AIX machines, it's difficult > to for me to do much about this. Let me know if you need > assistance in tracking this down. > > Some suggestions: > run "make LOG=info,cmdlines" to track the progress of the build. > > If you get lost in the log files, try running "make jre-image" > and then "rm build/$BUILD/images/jre", and then "make > LOG=info,cmdlines jre-image" to see only the output for the > jre-image target. > > Thanks for the hints! I'll try that. I played around last week > with make -d --print-data-base but got lost in the information. > > Last week I burned some time on this problem without much success. > I got stuck understanding the rule in Images.gmk: > > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > ? ? $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > $(ECHO) Creating jre jimage > $(RM) -r $(JRE_IMAGE_DIR) > ? ?$(JLINK_JRE_EXTRA_OPTS) \ > $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > ? ?--output $(JRE_IMAGE_DIR) > $(TOUCH) $@ > > and its brethren. > > It seems this rule just does not get executed for jre-image. So, > trying to understand this (I am no makefile expert): > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target > dir, in this case jre/java, whose non-existence or out-of-dateness > triggers the rule > > Dependencies: > > ?- $(JMODS) is /jmods, which gets built and does exist > > ?- $(call DependOnVariable, JRE_MODULES_LIST) > > This is just a macro that creates a dependency on the contents of the > variable JRE_MODULES_LIST. > > > $(BASE_RELEASE_FILE) is a text file which, if it exists and it > contains the value of $JRE_MODULES_LIST, will result false (not > out of date), otherwise it will update the file with the value of > $JRE_MODULES_LIST and return true, triggering the target, yes? If > I got this right, why do we use the same output file for all > targets (jre, jdk) etc? > > No, this is a separate dependency. It's the file named "release" in > the image that is to be included. If it has changed we need to trigger > a new image. > > Do you get to this stage at all? I.e, can you see "Createing jre > jimage" in the output? If not, there's a problem before we even get to > this rule. Otherwise, the jlink command is likely broken. Try > copy-pasting the full jlink command and running it from the shell > directly to see what happens. > > /Magnus > > ..Thomas > > /Magnus > > > > > I created https://bugs.openjdk.java.net/browse/JDK-8189618 > to track this. > > ..Thomas > > > > Lindenmaier, Goetz > 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 at openjdk.java.net > ] On Behalf > Of Steve Groeger > Sent: Mittwoch, 18. Oktober 2017 14:34 > To: ppc-aix-port-dev at 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Oct 25 12:57:23 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 25 Oct 2017 12:57:23 +0000 Subject: AIX build not generating a jre image In-Reply-To: References: <3c093f8a812f4b879a180de987f70e1c@sap.com> <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> Message-ID: <5ac4586d6f3442a79d245b5d7ba13f66@sap.com> Hi Magnus, thanks for your advice. Adding a bit of tracing to Images.gmk indeed helps to clarify the issue . Output of $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) looks nice and as expected on AIX . However it turns out the $(JRE_TARGETS) was empty on AIX , this leads to an empty dependency jre: $(JRE_TARGETS) on AIX in Images.gmk , and this leads to ?Nothing to be done for ?. ?. Background is that aix was not considered in the platform dependent parts of make/Images.gmk where JRE_TARGETS is filled for linux, macosx, solaris. I added aix there and the jre shows up in the images. Here is my diff (openjdk9) , still with tracing output AND with the added aix . Now JRE_TARGETS is not empty anymore which leads to successful generation of the JRE. Tracing output seen in the makefile + echo JRE_TARGETS are: /mygenerationdir/images/jre/man/man1/java.1 ?. Diff with tracing : diff -r a08cbfc0e4ec make/Images.gmk --- a/make/Images.gmk Thu Aug 03 18:56:56 2017 +0000 +++ b/make/Images.gmk Wed Oct 25 14:41:06 2017 +0200 @@ -43,6 +43,10 @@ $(eval $(call ReadImportMetaData)) +# helpful tracing +$(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) + + JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) JDK_MODULES += $(ALL_MODULES) @@ -295,7 +299,7 @@ $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, $(JDK_MAN_PAGES)) endif - ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) + ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, $(JRE_MAN_PAGES)) \ $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, $(JRE_MAN_PAGES)) \ $(JRE_IMAGE_DIR)/man/ja @@ -436,6 +440,8 @@ jdk: $(JDK_TARGETS) jre: $(JRE_TARGETS) + echo JRE_TARGETS are: $(JRE_TARGETS) , TOOL_JRE_TARGETS are: $(TOOL_JRE_TARGETS) + symbols: $(SYMBOLS_TARGETS) Best regards, Matthias From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] Sent: Mittwoch, 25. Oktober 2017 10:24 To: Baesken, Matthias ; Thomas St?fe Cc: build-dev (build-dev at openjdk.java.net) ; ppc-aix-port-dev at openjdk.java.net Subject: Re: AIX build not generating a jre image On 2017-10-24 16:44, Baesken, Matthias wrote: * Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? Hi Magnus, when comparing the linux and aix logs of our openjdk9 builds , I see for Linux at some point : gmake[3]: Entering directory ` . . . /nightly/jdk9/make' /bin/echo Creating jre jimage While on AIX it says : make[3]: Entering directory ` . . . /nightly/jdk9/make' make[3]: Nothing to be done for `jre'. make[3]: Leaving directory ` . . . /nightly/jdk9/make' this Looks wrong to me ! That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is considered up to date by make. This is wrong if that file does not exist. Are you *sure* you do not have a jre built? Verify the contents of these variables. Perhaps add a $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) at the top of Images.gmk, and check the location that is printed. /Magnus ( the . . . in the output has been removed by me it points to the build dir). Best regards, Matthias From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie Sent: Dienstag, 24. Oktober 2017 15:47 To: Thomas St?fe Cc: build-dev (build-dev at openjdk.java.net) ; ppc-aix-port-dev at openjdk.java.net Subject: Re: AIX build not generating a jre image On 2017-10-23 10:16, Thomas St?fe wrote: Hi Magnus, On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > wrote: On 2017-10-18 16:14, Thomas St?fe wrote: On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > 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. Since I don't have access to any AIX machines, it's difficult to for me to do much about this. Let me know if you need assistance in tracking this down. Some suggestions: run "make LOG=info,cmdlines" to track the progress of the build. If you get lost in the log files, try running "make jre-image" and then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines jre-image" to see only the output for the jre-image target. Thanks for the hints! I'll try that. I played around last week with make -d --print-data-base but got lost in the information. Last week I burned some time on this problem without much success. I got stuck understanding the rule in Images.gmk: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) $(ECHO) Creating jre jimage $(RM) -r $(JRE_IMAGE_DIR) $(JLINK_JRE_EXTRA_OPTS) \ $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ --output $(JRE_IMAGE_DIR) $(TOUCH) $@ and its brethren. It seems this rule just does not get executed for jre-image. So, trying to understand this (I am no makefile expert): $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target dir, in this case jre/java, whose non-existence or out-of-dateness triggers the rule Dependencies: - $(JMODS) is /jmods, which gets built and does exist - $(call DependOnVariable, JRE_MODULES_LIST) This is just a macro that creates a dependency on the contents of the variable JRE_MODULES_LIST. $(BASE_RELEASE_FILE) is a text file which, if it exists and it contains the value of $JRE_MODULES_LIST, will result false (not out of date), otherwise it will update the file with the value of $JRE_MODULES_LIST and return true, triggering the target, yes? If I got this right, why do we use the same output file for all targets (jre, jdk) etc? No, this is a separate dependency. It's the file named "release" in the image that is to be included. If it has changed we need to trigger a new image. Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? If not, there's a problem before we even get to this rule. Otherwise, the jlink command is likely broken. Try copy-pasting the full jlink command and running it from the shell directly to see what happens. /Magnus ..Thomas /Magnus I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. ..Thomas Lindenmaier, Goetz > 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 at openjdk.java.net] On Behalf Of Steve Groeger Sent: Mittwoch, 18. Oktober 2017 14:34 To: ppc-aix-port-dev at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Oct 25 13:21:32 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 25 Oct 2017 15:21:32 +0200 Subject: AIX build not generating a jre image In-Reply-To: <5ac4586d6f3442a79d245b5d7ba13f66@sap.com> References: <3c093f8a812f4b879a180de987f70e1c@sap.com> <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> <5ac4586d6f3442a79d245b5d7ba13f66@sap.com> Message-ID: <7181c04e-55cb-9699-fd4d-c1f6d55704fb@oracle.com> Ah, good find. I would argue that the correct fix is: jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) /Erik On 2017-10-25 14:57, Baesken, Matthias wrote: > Hi Magnus, thanks for your advice. > Adding a bit of tracing to Images.gmk indeed helps to clarify the issue . > Output of $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) looks nice and as expected on AIX . > However it turns out the $(JRE_TARGETS) was empty on AIX , this leads to an empty dependency > > jre: $(JRE_TARGETS) > > on AIX in Images.gmk , and this leads to ?Nothing to be done for ?. ?. > Background is that aix was not considered in the platform dependent parts of make/Images.gmk where JRE_TARGETS is filled for linux, macosx, solaris. > I added aix there and the jre shows up in the images. > Here is my diff (openjdk9) , still with tracing output AND with the added aix . > Now JRE_TARGETS is not empty anymore which leads to successful generation of the JRE. > > Tracing output seen in the makefile > + echo JRE_TARGETS are: /mygenerationdir/images/jre/man/man1/java.1 ?. > > > Diff with tracing : > > diff -r a08cbfc0e4ec make/Images.gmk > --- a/make/Images.gmk Thu Aug 03 18:56:56 2017 +0000 > +++ b/make/Images.gmk Wed Oct 25 14:41:06 2017 +0200 > @@ -43,6 +43,10 @@ > $(eval $(call ReadImportMetaData)) > +# helpful tracing > +$(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > + > + > JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ > $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) > JDK_MODULES += $(ALL_MODULES) > @@ -295,7 +299,7 @@ > $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, $(JDK_MAN_PAGES)) > endif > - ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) > + ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) > JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, $(JRE_MAN_PAGES)) \ > $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, $(JRE_MAN_PAGES)) \ > $(JRE_IMAGE_DIR)/man/ja > @@ -436,6 +440,8 @@ > jdk: $(JDK_TARGETS) > jre: $(JRE_TARGETS) > + echo JRE_TARGETS are: $(JRE_TARGETS) , TOOL_JRE_TARGETS are: $(TOOL_JRE_TARGETS) > + > symbols: $(SYMBOLS_TARGETS) > > > Best regards, Matthias > > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: Mittwoch, 25. Oktober 2017 10:24 > To: Baesken, Matthias ; Thomas St?fe > Cc: build-dev (build-dev at openjdk.java.net) ; ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX build not generating a jre image > > > On 2017-10-24 16:44, Baesken, Matthias wrote: > > * Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? > > Hi Magnus, when comparing the linux and aix logs of our openjdk9 builds , I see for Linux at some point : > > > > gmake[3]: Entering directory ` . . . /nightly/jdk9/make' > > /bin/echo Creating jre jimage > > > While on AIX it says : > > > make[3]: Entering directory ` . . . /nightly/jdk9/make' > > make[3]: Nothing to be done for `jre'. > > make[3]: Leaving directory ` . . . /nightly/jdk9/make' > > > this Looks wrong to me ! > That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is considered up to date by make. This is wrong if that file does not exist. Are you *sure* you do not have a jre built? > Verify the contents of these variables. Perhaps add a > $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > at the top of Images.gmk, > and check the location that is printed. > > /Magnus > > > > > ( the . . . in the output has been removed by me it points to the build dir). > > Best regards, Matthias > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie > Sent: Dienstag, 24. Oktober 2017 15:47 > To: Thomas St?fe > Cc: build-dev (build-dev at openjdk.java.net) ; ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX build not generating a jre image > > On 2017-10-23 10:16, Thomas St?fe wrote: > Hi Magnus, > > On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > wrote: > > On 2017-10-18 16:14, Thomas St?fe wrote: > On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > > 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. > Since I don't have access to any AIX machines, it's difficult to for me to do much about this. Let me know if you need assistance in tracking this down. > > Some suggestions: > run "make LOG=info,cmdlines" to track the progress of the build. > > If you get lost in the log files, try running "make jre-image" and then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines jre-image" to see only the output for the jre-image target. > > Thanks for the hints! I'll try that. I played around last week with make -d --print-data-base but got lost in the information. > > Last week I burned some time on this problem without much success. I got stuck understanding the rule in Images.gmk: > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > $(ECHO) Creating jre jimage > $(RM) -r $(JRE_IMAGE_DIR) > $(JLINK_JRE_EXTRA_OPTS) \ > $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > --output $(JRE_IMAGE_DIR) > $(TOUCH) $@ > > and its brethren. > > It seems this rule just does not get executed for jre-image. So, trying to understand this (I am no makefile expert): > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target dir, in this case jre/java, whose non-existence or out-of-dateness triggers the rule > > Dependencies: > - $(JMODS) is /jmods, which gets built and does exist > - $(call DependOnVariable, JRE_MODULES_LIST) > This is just a macro that creates a dependency on the contents of the variable JRE_MODULES_LIST. > > > > $(BASE_RELEASE_FILE) is a text file which, if it exists and it contains the value of $JRE_MODULES_LIST, will result false (not out of date), otherwise it will update the file with the value of $JRE_MODULES_LIST and return true, triggering the target, yes? If I got this right, why do we use the same output file for all targets (jre, jdk) etc? > No, this is a separate dependency. It's the file named "release" in the image that is to be included. If it has changed we need to trigger a new image. > > Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the output? If not, there's a problem before we even get to this rule. Otherwise, the jlink command is likely broken. Try copy-pasting the full jlink command and running it from the shell directly to see what happens. > > /Magnus > > > > ..Thomas > > > > /Magnus > > > > > I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. > > ..Thomas > > > > > Lindenmaier, Goetz > 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 at openjdk.java.net] On Behalf Of Steve Groeger > Sent: Mittwoch, 18. Oktober 2017 14:34 > To: ppc-aix-port-dev at 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 at 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 > > > > > From matthias.baesken at sap.com Wed Oct 25 14:35:14 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 25 Oct 2017 14:35:14 +0000 Subject: AIX build not generating a jre image In-Reply-To: <7181c04e-55cb-9699-fd4d-c1f6d55704fb@oracle.com> References: <3c093f8a812f4b879a180de987f70e1c@sap.com> <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> <5ac4586d6f3442a79d245b5d7ba13f66@sap.com> <7181c04e-55cb-9699-fd4d-c1f6d55704fb@oracle.com> Message-ID: <132e776c28894f7b890ceb9baca2628f@sap.com> Thanks Erik. I check your suggestion with jdk10/master on AIX . Best regards, Matthias > -----Original Message----- > From: Erik Joelsson [mailto:erik.joelsson at oracle.com] > Sent: Mittwoch, 25. Oktober 2017 15:22 > To: Baesken, Matthias ; Magnus Ihse Bursie > ; Thomas St?fe > > Cc: build-dev (build-dev at openjdk.java.net) ; > ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX build not generating a jre image > > Ah, good find. I would argue that the correct fix is: > > jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) > jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) > > /Erik > > On 2017-10-25 14:57, Baesken, Matthias wrote: > > Hi Magnus, thanks for your advice. > > Adding a bit of tracing to Images.gmk indeed helps to clarify the issue . > > Output of $(info this is the jre location: > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) looks nice and as expected > on AIX . > > However it turns out the $(JRE_TARGETS) was empty on AIX , this leads > to an empty dependency > > > > jre: $(JRE_TARGETS) > > > > on AIX in Images.gmk , and this leads to ?Nothing to be done for ?. ?. > > Background is that aix was not considered in the platform dependent > parts of make/Images.gmk where JRE_TARGETS is filled for linux, macosx, > solaris. > > I added aix there and the jre shows up in the images. > > Here is my diff (openjdk9) , still with tracing output AND with the added > aix . > > Now JRE_TARGETS is not empty anymore which leads to successful > generation of the JRE. > > > > Tracing output seen in the makefile > > + echo JRE_TARGETS are: /mygenerationdir/images/jre/man/man1/java.1 > ?. > > > > > > Diff with tracing : > > > > diff -r a08cbfc0e4ec make/Images.gmk > > --- a/make/Images.gmk Thu Aug 03 18:56:56 2017 +0000 > > +++ b/make/Images.gmk Wed Oct 25 14:41:06 2017 +0200 > > @@ -43,6 +43,10 @@ > > $(eval $(call ReadImportMetaData)) > > +# helpful tracing > > +$(info this is the jre location: > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > > + > > + > > JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ > > $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) > > JDK_MODULES += $(ALL_MODULES) > > @@ -295,7 +299,7 @@ > > $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, > $(JDK_MAN_PAGES)) > > endif > > - ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) > > + ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) > > JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, > $(JRE_MAN_PAGES)) \ > > $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, > $(JRE_MAN_PAGES)) \ > > $(JRE_IMAGE_DIR)/man/ja > > @@ -436,6 +440,8 @@ > > jdk: $(JDK_TARGETS) > > jre: $(JRE_TARGETS) > > + echo JRE_TARGETS are: $(JRE_TARGETS) , TOOL_JRE_TARGETS are: > $(TOOL_JRE_TARGETS) > > + > > symbols: $(SYMBOLS_TARGETS) > > > > > > Best regards, Matthias > > > > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > > Sent: Mittwoch, 25. Oktober 2017 10:24 > > To: Baesken, Matthias ; Thomas St?fe > > > Cc: build-dev (build-dev at openjdk.java.net) dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net > > Subject: Re: AIX build not generating a jre image > > > > > > On 2017-10-24 16:44, Baesken, Matthias wrote: > > > > * Do you get to this stage at all? I.e, can you see "Createing jre jimage" in > the output? > > > > Hi Magnus, when comparing the linux and aix logs of our openjdk9 builds , > I see for Linux at some point : > > > > > > > > gmake[3]: Entering directory ` . . . /nightly/jdk9/make' > > > > /bin/echo Creating jre jimage > > > > > > While on AIX it says : > > > > > > make[3]: Entering directory ` . . . /nightly/jdk9/make' > > > > make[3]: Nothing to be done for `jre'. > > > > make[3]: Leaving directory ` . . . /nightly/jdk9/make' > > > > > > this Looks wrong to me ! > > That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is > considered up to date by make. This is wrong if that file does not exist. Are > you *sure* you do not have a jre built? > > Verify the contents of these variables. Perhaps add a > > $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > > at the top of Images.gmk, > > and check the location that is printed. > > > > /Magnus > > > > > > > > > > ( the . . . in the output has been removed by me it points to the build > dir). > > > > Best regards, Matthias > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie > > Sent: Dienstag, 24. Oktober 2017 15:47 > > To: Thomas St?fe > > > Cc: build-dev (build-dev at openjdk.java.net dev at openjdk.java.net>) dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net aix-port-dev at openjdk.java.net> > > Subject: Re: AIX build not generating a jre image > > > > On 2017-10-23 10:16, Thomas St?fe wrote: > > Hi Magnus, > > > > On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > > > wrote: > > > > On 2017-10-18 16:14, Thomas St?fe wrote: > > On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > > > > 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. > > Since I don't have access to any AIX machines, it's difficult to for me to do > much about this. Let me know if you need assistance in tracking this down. > > > > Some suggestions: > > run "make LOG=info,cmdlines" to track the progress of the build. > > > > If you get lost in the log files, try running "make jre-image" and then "rm > build/$BUILD/images/jre", and then "make LOG=info,cmdlines jre-image" to > see only the output for the jre-image target. > > > > Thanks for the hints! I'll try that. I played around last week with make -d -- > print-data-base but got lost in the information. > > > > Last week I burned some time on this problem without much success. I got > stuck understanding the rule in Images.gmk: > > > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > > $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > > $(ECHO) Creating jre jimage > > $(RM) -r $(JRE_IMAGE_DIR) > > $(JLINK_JRE_EXTRA_OPTS) \ > > $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > > --output $(JRE_IMAGE_DIR) > > $(TOUCH) $@ > > > > and its brethren. > > > > It seems this rule just does not get executed for jre-image. So, trying to > understand this (I am no makefile expert): > > > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target dir, > in this case jre/java, whose non-existence or out-of-dateness triggers the > rule > > > > Dependencies: > > - $(JMODS) is /jmods, which gets built and does exist > > - $(call DependOnVariable, JRE_MODULES_LIST) > > This is just a macro that creates a dependency on the contents of the > variable JRE_MODULES_LIST. > > > > > > > > $(BASE_RELEASE_FILE) is a text file which, if it exists and it contains the > value of $JRE_MODULES_LIST, will result false (not out of date), otherwise it > will update the file with the value of $JRE_MODULES_LIST and return true, > triggering the target, yes? If I got this right, why do we use the same output > file for all targets (jre, jdk) etc? > > No, this is a separate dependency. It's the file named "release" in the > image that is to be included. If it has changed we need to trigger a new > image. > > > > Do you get to this stage at all? I.e, can you see "Createing jre jimage" in the > output? If not, there's a problem before we even get to this rule. Otherwise, > the jlink command is likely broken. Try copy-pasting the full jlink command > and running it from the shell directly to see what happens. > > > > /Magnus > > > > > > > > ..Thomas > > > > > > > > /Magnus > > > > > > > > > > I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track this. > > > > ..Thomas > > > > > > > > > > Lindenmaier, Goetz > > > 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 at openjdk.java.net] On > Behalf Of Steve Groeger > > Sent: Mittwoch, 18. Oktober 2017 14:34 > > To: ppc-aix-port-dev at openjdk.java.net dev at 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 at 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 > > > > > > > > > > From magnus.ihse.bursie at oracle.com Wed Oct 25 14:45:44 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Oct 2017 16:45:44 +0200 Subject: AIX build not generating a jre image In-Reply-To: <7181c04e-55cb-9699-fd4d-c1f6d55704fb@oracle.com> References: <3c093f8a812f4b879a180de987f70e1c@sap.com> <1824dec0-2800-035f-92e1-8e73cf87ce25@oracle.com> <5ac4586d6f3442a79d245b5d7ba13f66@sap.com> <7181c04e-55cb-9699-fd4d-c1f6d55704fb@oracle.com> Message-ID: <503042d6-69b7-2d8e-720e-bfa562fa3b74@oracle.com> On 2017-10-25 15:21, Erik Joelsson wrote: > Ah, good find. I would argue that the correct fix is: > > jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) > jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) Yeah, good find Matthias! I agree with Erik's suggested fix. This is a bit of "how has this ever worked?!?". It turns out that our closed extensions are unconditionally adding targets to JRE_TARGETS, so we never noticed that it could happen that JRE_TARGETS are empty, and the building of the JRE image does not work. This will happen on Windows as well as AIX. /Magnus > > /Erik > > On 2017-10-25 14:57, Baesken, Matthias wrote: >> Hi Magnus, thanks for your advice. >> Adding a bit of tracing? to? Images.gmk? indeed helps to clarify the >> issue? . >> Output of????? $(info this is the jre location: >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE))??? looks nice and as expected >> on AIX . >> However it turns out the?? $(JRE_TARGETS)?? was empty? on AIX ,?? >> this leads to an empty dependency >> >> jre: $(JRE_TARGETS) >> >> on AIX in? Images.gmk ,? and this leads to ?Nothing to be done for ?. ?. >> Background is that? aix was not considered?? in the platform >> dependent? parts of? make/Images.gmk? where? JRE_TARGETS is filled >> for linux, macosx, solaris. >> I added? aix there and? the jre? shows up in the images. >> Here is my diff? (openjdk9) ,? still with tracing output AND with >> the? added aix . >> Now? JRE_TARGETS? is not empty anymore which leads to successful? >> generation of the JRE. >> >> Tracing output seen in the makefile >> + echo JRE_TARGETS are: /mygenerationdir/images/jre/man/man1/java.1?? ?. >> >> >> Diff with tracing : >> >> diff -r a08cbfc0e4ec make/Images.gmk >> --- a/make/Images.gmk?? Thu Aug 03 18:56:56 2017 +0000 >> +++ b/make/Images.gmk?? Wed Oct 25 14:41:06 2017 +0200 >> @@ -43,6 +43,10 @@ >> ? $(eval $(call ReadImportMetaData)) >> +# helpful tracing >> +$(info this is the jre location: >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) >> + >> + >> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ >> ????? $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) >> JDK_MODULES += $(ALL_MODULES) >> @@ -295,7 +299,7 @@ >> ????????? $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, >> $(JDK_MAN_PAGES)) >> ??? endif >> -? ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) >> +? ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) >> ????? JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, >> $(JRE_MAN_PAGES)) \ >> ????????? $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, >> $(JRE_MAN_PAGES)) \ >> ????????? $(JRE_IMAGE_DIR)/man/ja >> @@ -436,6 +440,8 @@ >> ? jdk: $(JDK_TARGETS) >> jre: $(JRE_TARGETS) >> +?????? echo JRE_TARGETS are: $(JRE_TARGETS) ,? TOOL_JRE_TARGETS are: >> $(TOOL_JRE_TARGETS) >> + >> symbols: $(SYMBOLS_TARGETS) >> >> >> Best regards, Matthias >> >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >> Sent: Mittwoch, 25. Oktober 2017 10:24 >> To: Baesken, Matthias ; Thomas St?fe >> >> Cc: build-dev (build-dev at openjdk.java.net) >> ; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: AIX build not generating a jre image >> >> >> On 2017-10-24 16:44, Baesken, Matthias wrote: >> >> ?? *?? Do you get to this stage at all? I.e, can you see "Createing >> jre jimage" in the output? >> >> Hi Magnus, when comparing the linux and aix logs? of our openjdk9 >> builds? ,?? I see for Linux at some point : >> >> >> >> gmake[3]: Entering directory ` . . . /nightly/jdk9/make' >> >> /bin/echo Creating jre jimage >> >> >> While on AIX it says : >> >> >> make[3]: Entering directory ` . . . /nightly/jdk9/make' >> >> make[3]: Nothing to be done for `jre'. >> >> make[3]: Leaving directory ` . . . /nightly/jdk9/make' >> >> >> this Looks wrong to me ! >> That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is considered >> up to date by make. This is wrong if that file does not exist. Are >> you *sure* you do not have a jre built? >> Verify the contents of these variables. Perhaps add a >> $(info this is the jre location: $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) >> at the top of Images.gmk, >> and check the location that is printed. >> >> /Magnus >> >> >> >> >> (? the?? . . .?? in the output has been removed by me it points to >> the build dir). >> >> Best regards, Matthias >> >> >> From: ppc-aix-port-dev >> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >> Magnus Ihse Bursie >> Sent: Dienstag, 24. Oktober 2017 15:47 >> To: Thomas St?fe >> >> Cc: build-dev >> (build-dev at openjdk.java.net) >> ; >> ppc-aix-port-dev at openjdk.java.net >> >> Subject: Re: AIX build not generating a jre image >> >> On 2017-10-23 10:16, Thomas St?fe wrote: >> Hi Magnus, >> >> On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie >> > >> wrote: >> >> On 2017-10-18 16:14, Thomas St?fe wrote: >> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis >> > >> 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. >> Since I don't have access to any AIX machines, it's difficult to for >> me to do much about this. Let me know if you need assistance in >> tracking this down. >> >> Some suggestions: >> run "make LOG=info,cmdlines" to track the progress of the build. >> >> If you get lost in the log files, try running "make jre-image" and >> then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines >> jre-image" to see only the output for the jre-image target. >> >> Thanks for the hints! I'll try that. I played around last week with >> make -d --print-data-base but got lost in the information. >> >> Last week I burned some time on this problem without much success. I >> got stuck understanding the rule in Images.gmk: >> >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ >> ???? $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) >> $(ECHO) Creating jre jimage >> $(RM) -r $(JRE_IMAGE_DIR) >> ??? $(JLINK_JRE_EXTRA_OPTS) \ >> $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ >> ??? --output $(JRE_IMAGE_DIR) >> $(TOUCH) $@ >> >> and its brethren. >> >> It seems this rule just does not get executed for jre-image. So, >> trying to understand this (I am no makefile expert): >> >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target >> dir, in this case jre/java, whose non-existence or out-of-dateness >> triggers the rule >> >> Dependencies: >> ? - $(JMODS) is /jmods, which gets built and does exist >> ? - $(call DependOnVariable, JRE_MODULES_LIST) >> This is just a macro that creates a dependency on the contents of the >> variable JRE_MODULES_LIST. >> >> >> >> $(BASE_RELEASE_FILE) is a text file which, if it exists and it >> contains the value of $JRE_MODULES_LIST, will result false (not out >> of date), otherwise it will update the file with the value of >> $JRE_MODULES_LIST and return true, triggering the target, yes? If I >> got this right, why do we use the same output file for all targets >> (jre, jdk) etc? >> No, this is a separate dependency. It's the file named "release" in >> the image that is to be included. If it has changed we need to >> trigger a new image. >> >> Do you get to this stage at all? I.e, can you see "Createing jre >> jimage" in the output? If not, there's a problem before we even get >> to this rule. Otherwise, the jlink command is likely broken. Try >> copy-pasting the full jlink command and running it from the shell >> directly to see what happens. >> >> /Magnus >> >> >> >> ..Thomas >> >> >> >> /Magnus >> >> >> >> >> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track >> this. >> >> ..Thomas >> >> >> >> >> Lindenmaier, Goetz >> > 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 at openjdk.java.net] On Behalf >> Of Steve Groeger >> Sent: Mittwoch, 18. Oktober 2017 14:34 >> To: >> ppc-aix-port-dev at 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 at 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 >> >> >> >> >> > From matthias.baesken at sap.com Thu Oct 26 07:05:02 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 26 Oct 2017 07:05:02 +0000 Subject: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image Message-ID: <5c0ef56a3c1a4c15822f05f84f1e0613@sap.com> Hello , could you please review and push this small change fixing the aix jre generation in jdk10 : http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ (and later on it would be good to get it into jdk9 as well because the same issue exists there too) Thanks and best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: Mittwoch, 25. Oktober 2017 16:46 > To: Erik Joelsson ; Baesken, Matthias > ; Thomas St?fe > Cc: build-dev (build-dev at openjdk.java.net) ; > ppc-aix-port-dev at openjdk.java.net > Subject: Re: AIX build not generating a jre image > > On 2017-10-25 15:21, Erik Joelsson wrote: > > Ah, good find. I would argue that the correct fix is: > > > > jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) > > jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) > > Yeah, good find Matthias! > > I agree with Erik's suggested fix. This is a bit of "how has this ever > worked?!?". It turns out that our closed extensions are unconditionally > adding targets to JRE_TARGETS, so we never noticed that it could happen > that JRE_TARGETS are empty, and the building of the JRE image does not > work. This will happen on Windows as well as AIX. > > /Magnus > > > > > /Erik > > > > On 2017-10-25 14:57, Baesken, Matthias wrote: > >> Hi Magnus, thanks for your advice. > >> Adding a bit of tracing? to? Images.gmk? indeed helps to clarify the > >> issue? . > >> Output of????? $(info this is the jre location: > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE))??? looks nice and as > expected > >> on AIX . > >> However it turns out the?? $(JRE_TARGETS)?? was empty? on AIX , > >> this leads to an empty dependency > >> > >> jre: $(JRE_TARGETS) > >> > >> on AIX in? Images.gmk ,? and this leads to ?Nothing to be done for ?. ?. > >> Background is that? aix was not considered?? in the platform > >> dependent? parts of? make/Images.gmk? where? JRE_TARGETS is filled > >> for linux, macosx, solaris. > >> I added? aix there and? the jre? shows up in the images. > >> Here is my diff? (openjdk9) ,? still with tracing output AND with > >> the? added aix . > >> Now? JRE_TARGETS? is not empty anymore which leads to successful > >> generation of the JRE. > >> > >> Tracing output seen in the makefile > >> + echo JRE_TARGETS are: > /mygenerationdir/images/jre/man/man1/java.1?? ?. > >> > >> > >> Diff with tracing : > >> > >> diff -r a08cbfc0e4ec make/Images.gmk > >> --- a/make/Images.gmk?? Thu Aug 03 18:56:56 2017 +0000 > >> +++ b/make/Images.gmk?? Wed Oct 25 14:41:06 2017 +0200 > >> @@ -43,6 +43,10 @@ > >> ? $(eval $(call ReadImportMetaData)) > >> +# helpful tracing > >> +$(info this is the jre location: > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > >> + > >> + > >> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ > >> ????? $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) > >> JDK_MODULES += $(ALL_MODULES) > >> @@ -295,7 +299,7 @@ > >> ????????? $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, > >> $(JDK_MAN_PAGES)) > >> ??? endif > >> -? ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) > >> +? ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) > >> ????? JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, > >> $(JRE_MAN_PAGES)) \ > >> ????????? $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, > >> $(JRE_MAN_PAGES)) \ > >> ????????? $(JRE_IMAGE_DIR)/man/ja > >> @@ -436,6 +440,8 @@ > >> ? jdk: $(JDK_TARGETS) > >> jre: $(JRE_TARGETS) > >> +?????? echo JRE_TARGETS are: $(JRE_TARGETS) ,? TOOL_JRE_TARGETS are: > >> $(TOOL_JRE_TARGETS) > >> + > >> symbols: $(SYMBOLS_TARGETS) > >> > >> > >> Best regards, Matthias > >> > >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > >> Sent: Mittwoch, 25. Oktober 2017 10:24 > >> To: Baesken, Matthias ; Thomas St?fe > >> > >> Cc: build-dev (build-dev at openjdk.java.net) > >> ; ppc-aix-port-dev at openjdk.java.net > >> Subject: Re: AIX build not generating a jre image > >> > >> > >> On 2017-10-24 16:44, Baesken, Matthias wrote: > >> > >> ?? *?? Do you get to this stage at all? I.e, can you see "Createing > >> jre jimage" in the output? > >> > >> Hi Magnus, when comparing the linux and aix logs? of our openjdk9 > >> builds? ,?? I see for Linux at some point : > >> > >> > >> > >> gmake[3]: Entering directory ` . . . /nightly/jdk9/make' > >> > >> /bin/echo Creating jre jimage > >> > >> > >> While on AIX it says : > >> > >> > >> make[3]: Entering directory ` . . . /nightly/jdk9/make' > >> > >> make[3]: Nothing to be done for `jre'. > >> > >> make[3]: Leaving directory ` . . . /nightly/jdk9/make' > >> > >> > >> this Looks wrong to me ! > >> That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is > considered > >> up to date by make. This is wrong if that file does not exist. Are > >> you *sure* you do not have a jre built? > >> Verify the contents of these variables. Perhaps add a > >> $(info this is the jre location: > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > >> at the top of Images.gmk, > >> and check the location that is printed. > >> > >> /Magnus > >> > >> > >> > >> > >> (? the?? . . .?? in the output has been removed by me it points to > >> the build dir). > >> > >> Best regards, Matthias > >> > >> > >> From: ppc-aix-port-dev > >> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of > >> Magnus Ihse Bursie > >> Sent: Dienstag, 24. Oktober 2017 15:47 > >> To: Thomas St?fe > >> > >> Cc: build-dev > >> (build-dev at openjdk.java.net) > >> ; > >> ppc-aix-port-dev at openjdk.java.net dev at openjdk.java.net> > >> > >> Subject: Re: AIX build not generating a jre image > >> > >> On 2017-10-23 10:16, Thomas St?fe wrote: > >> Hi Magnus, > >> > >> On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > >> > > > > >> wrote: > >> > >> On 2017-10-18 16:14, Thomas St?fe wrote: > >> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > >> > > >> 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. > >> Since I don't have access to any AIX machines, it's difficult to for > >> me to do much about this. Let me know if you need assistance in > >> tracking this down. > >> > >> Some suggestions: > >> run "make LOG=info,cmdlines" to track the progress of the build. > >> > >> If you get lost in the log files, try running "make jre-image" and > >> then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines > >> jre-image" to see only the output for the jre-image target. > >> > >> Thanks for the hints! I'll try that. I played around last week with > >> make -d --print-data-base but got lost in the information. > >> > >> Last week I burned some time on this problem without much success. I > >> got stuck understanding the rule in Images.gmk: > >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > >> ???? $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > >> $(ECHO) Creating jre jimage > >> $(RM) -r $(JRE_IMAGE_DIR) > >> ??? $(JLINK_JRE_EXTRA_OPTS) \ > >> $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > >> ??? --output $(JRE_IMAGE_DIR) > >> $(TOUCH) $@ > >> > >> and its brethren. > >> > >> It seems this rule just does not get executed for jre-image. So, > >> trying to understand this (I am no makefile expert): > >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target > >> dir, in this case jre/java, whose non-existence or out-of-dateness > >> triggers the rule > >> > >> Dependencies: > >> ? - $(JMODS) is /jmods, which gets built and does exist > >> ? - $(call DependOnVariable, JRE_MODULES_LIST) > >> This is just a macro that creates a dependency on the contents of the > >> variable JRE_MODULES_LIST. > >> > >> > >> > >> $(BASE_RELEASE_FILE) is a text file which, if it exists and it > >> contains the value of $JRE_MODULES_LIST, will result false (not out > >> of date), otherwise it will update the file with the value of > >> $JRE_MODULES_LIST and return true, triggering the target, yes? If I > >> got this right, why do we use the same output file for all targets > >> (jre, jdk) etc? > >> No, this is a separate dependency. It's the file named "release" in > >> the image that is to be included. If it has changed we need to > >> trigger a new image. > >> > >> Do you get to this stage at all? I.e, can you see "Createing jre > >> jimage" in the output? If not, there's a problem before we even get > >> to this rule. Otherwise, the jlink command is likely broken. Try > >> copy-pasting the full jlink command and running it from the shell > >> directly to see what happens. > >> > >> /Magnus > >> > >> > >> > >> ..Thomas > >> > >> > >> > >> /Magnus > >> > >> > >> > >> > >> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track > >> this. > >> > >> ..Thomas > >> > >> > >> > >> > >> Lindenmaier, Goetz > >> > > 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 at openjdk.java.net] On > Behalf > >> Of Steve Groeger > >> Sent: Mittwoch, 18. Oktober 2017 14:34 > >> To: > >> ppc-aix-port-dev at openjdk.java.net dev at 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 at 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 > >> > >> > >> > >> > >> > > From erik.joelsson at oracle.com Thu Oct 26 07:36:39 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Oct 2017 09:36:39 +0200 Subject: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image In-Reply-To: <5c0ef56a3c1a4c15822f05f84f1e0613@sap.com> References: <5c0ef56a3c1a4c15822f05f84f1e0613@sap.com> Message-ID: <6603e0a9-0d73-baaa-9691-7319a6609c75@oracle.com> Looks good. /Erik On 2017-10-26 09:05, Baesken, Matthias wrote: > Hello , could you please review and push this small change fixing the aix jre generation in jdk10 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ > > > (and later on it would be good to get it into jdk9 as well because the same issue exists there too) > > Thanks and best regards, Matthias > > >> -----Original Message----- >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >> Sent: Mittwoch, 25. Oktober 2017 16:46 >> To: Erik Joelsson ; Baesken, Matthias >> ; Thomas St?fe >> Cc: build-dev (build-dev at openjdk.java.net) ; >> ppc-aix-port-dev at openjdk.java.net >> Subject: Re: AIX build not generating a jre image >> >> On 2017-10-25 15:21, Erik Joelsson wrote: >>> Ah, good find. I would argue that the correct fix is: >>> >>> jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) >>> jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) >> Yeah, good find Matthias! >> >> I agree with Erik's suggested fix. This is a bit of "how has this ever >> worked?!?". It turns out that our closed extensions are unconditionally >> adding targets to JRE_TARGETS, so we never noticed that it could happen >> that JRE_TARGETS are empty, and the building of the JRE image does not >> work. This will happen on Windows as well as AIX. >> >> /Magnus >> >>> /Erik >>> >>> On 2017-10-25 14:57, Baesken, Matthias wrote: >>>> Hi Magnus, thanks for your advice. >>>> Adding a bit of tracing? to? Images.gmk? indeed helps to clarify the >>>> issue? . >>>> Output of????? $(info this is the jre location: >>>> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE))??? looks nice and as >> expected >>>> on AIX . >>>> However it turns out the?? $(JRE_TARGETS)?? was empty? on AIX , >>>> this leads to an empty dependency >>>> >>>> jre: $(JRE_TARGETS) >>>> >>>> on AIX in? Images.gmk ,? and this leads to ?Nothing to be done for ?. ?. >>>> Background is that? aix was not considered?? in the platform >>>> dependent? parts of? make/Images.gmk? where? JRE_TARGETS is filled >>>> for linux, macosx, solaris. >>>> I added? aix there and? the jre? shows up in the images. >>>> Here is my diff? (openjdk9) ,? still with tracing output AND with >>>> the? added aix . >>>> Now? JRE_TARGETS? is not empty anymore which leads to successful >>>> generation of the JRE. >>>> >>>> Tracing output seen in the makefile >>>> + echo JRE_TARGETS are: >> /mygenerationdir/images/jre/man/man1/java.1?? ?. >>>> >>>> Diff with tracing : >>>> >>>> diff -r a08cbfc0e4ec make/Images.gmk >>>> --- a/make/Images.gmk?? Thu Aug 03 18:56:56 2017 +0000 >>>> +++ b/make/Images.gmk?? Wed Oct 25 14:41:06 2017 +0200 >>>> @@ -43,6 +43,10 @@ >>>> ? $(eval $(call ReadImportMetaData)) >>>> +# helpful tracing >>>> +$(info this is the jre location: >>>> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) >>>> + >>>> + >>>> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ >>>> ????? $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) >>>> JDK_MODULES += $(ALL_MODULES) >>>> @@ -295,7 +299,7 @@ >>>> ????????? $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, >>>> $(JDK_MAN_PAGES)) >>>> ??? endif >>>> -? ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) >>>> +? ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) >>>> ????? JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, >>>> $(JRE_MAN_PAGES)) \ >>>> ????????? $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, >>>> $(JRE_MAN_PAGES)) \ >>>> ????????? $(JRE_IMAGE_DIR)/man/ja >>>> @@ -436,6 +440,8 @@ >>>> ? jdk: $(JDK_TARGETS) >>>> jre: $(JRE_TARGETS) >>>> +?????? echo JRE_TARGETS are: $(JRE_TARGETS) ,? TOOL_JRE_TARGETS are: >>>> $(TOOL_JRE_TARGETS) >>>> + >>>> symbols: $(SYMBOLS_TARGETS) >>>> >>>> >>>> Best regards, Matthias >>>> >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >>>> Sent: Mittwoch, 25. Oktober 2017 10:24 >>>> To: Baesken, Matthias ; Thomas St?fe >>>> >>>> Cc: build-dev (build-dev at openjdk.java.net) >>>> ; ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: AIX build not generating a jre image >>>> >>>> >>>> On 2017-10-24 16:44, Baesken, Matthias wrote: >>>> >>>> ?? *?? Do you get to this stage at all? I.e, can you see "Createing >>>> jre jimage" in the output? >>>> >>>> Hi Magnus, when comparing the linux and aix logs? of our openjdk9 >>>> builds? ,?? I see for Linux at some point : >>>> >>>> >>>> >>>> gmake[3]: Entering directory ` . . . /nightly/jdk9/make' >>>> >>>> /bin/echo Creating jre jimage >>>> >>>> >>>> While on AIX it says : >>>> >>>> >>>> make[3]: Entering directory ` . . . /nightly/jdk9/make' >>>> >>>> make[3]: Nothing to be done for `jre'. >>>> >>>> make[3]: Leaving directory ` . . . /nightly/jdk9/make' >>>> >>>> >>>> this Looks wrong to me ! >>>> That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is >> considered >>>> up to date by make. This is wrong if that file does not exist. Are >>>> you *sure* you do not have a jre built? >>>> Verify the contents of these variables. Perhaps add a >>>> $(info this is the jre location: >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) >>>> at the top of Images.gmk, >>>> and check the location that is printed. >>>> >>>> /Magnus >>>> >>>> >>>> >>>> >>>> (? the?? . . .?? in the output has been removed by me it points to >>>> the build dir). >>>> >>>> Best regards, Matthias >>>> >>>> >>>> From: ppc-aix-port-dev >>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>> Magnus Ihse Bursie >>>> Sent: Dienstag, 24. Oktober 2017 15:47 >>>> To: Thomas St?fe >>>> >>>> Cc: build-dev >>>> (build-dev at openjdk.java.net) >>>> ; >>>> ppc-aix-port-dev at openjdk.java.net> dev at openjdk.java.net> >>>> Subject: Re: AIX build not generating a jre image >>>> >>>> On 2017-10-23 10:16, Thomas St?fe wrote: >>>> Hi Magnus, >>>> >>>> On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie >>>> >> >>>> wrote: >>>> >>>> On 2017-10-18 16:14, Thomas St?fe wrote: >>>> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis >>>> > >>>> 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. >>>> Since I don't have access to any AIX machines, it's difficult to for >>>> me to do much about this. Let me know if you need assistance in >>>> tracking this down. >>>> >>>> Some suggestions: >>>> run "make LOG=info,cmdlines" to track the progress of the build. >>>> >>>> If you get lost in the log files, try running "make jre-image" and >>>> then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines >>>> jre-image" to see only the output for the jre-image target. >>>> >>>> Thanks for the hints! I'll try that. I played around last week with >>>> make -d --print-data-base but got lost in the information. >>>> >>>> Last week I burned some time on this problem without much success. I >>>> got stuck understanding the rule in Images.gmk: >>>> >>>> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ >>>> ???? $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) >>>> $(ECHO) Creating jre jimage >>>> $(RM) -r $(JRE_IMAGE_DIR) >>>> ??? $(JLINK_JRE_EXTRA_OPTS) \ >>>> $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ >>>> ??? --output $(JRE_IMAGE_DIR) >>>> $(TOUCH) $@ >>>> >>>> and its brethren. >>>> >>>> It seems this rule just does not get executed for jre-image. So, >>>> trying to understand this (I am no makefile expert): >>>> >>>> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target >>>> dir, in this case jre/java, whose non-existence or out-of-dateness >>>> triggers the rule >>>> >>>> Dependencies: >>>> ? - $(JMODS) is /jmods, which gets built and does exist >>>> ? - $(call DependOnVariable, JRE_MODULES_LIST) >>>> This is just a macro that creates a dependency on the contents of the >>>> variable JRE_MODULES_LIST. >>>> >>>> >>>> >>>> $(BASE_RELEASE_FILE) is a text file which, if it exists and it >>>> contains the value of $JRE_MODULES_LIST, will result false (not out >>>> of date), otherwise it will update the file with the value of >>>> $JRE_MODULES_LIST and return true, triggering the target, yes? If I >>>> got this right, why do we use the same output file for all targets >>>> (jre, jdk) etc? >>>> No, this is a separate dependency. It's the file named "release" in >>>> the image that is to be included. If it has changed we need to >>>> trigger a new image. >>>> >>>> Do you get to this stage at all? I.e, can you see "Createing jre >>>> jimage" in the output? If not, there's a problem before we even get >>>> to this rule. Otherwise, the jlink command is likely broken. Try >>>> copy-pasting the full jlink command and running it from the shell >>>> directly to see what happens. >>>> >>>> /Magnus >>>> >>>> >>>> >>>> ..Thomas >>>> >>>> >>>> >>>> /Magnus >>>> >>>> >>>> >>>> >>>> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track >>>> this. >>>> >>>> ..Thomas >>>> >>>> >>>> >>>> >>>> Lindenmaier, Goetz >>>> > >> 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 at openjdk.java.net] On >> Behalf >>>> Of Steve Groeger >>>> Sent: Mittwoch, 18. Oktober 2017 14:34 >>>> To: >>>> ppc-aix-port-dev at openjdk.java.net> dev at 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 at 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 >>>> >>>> >>>> >>>> >>>> From thomas.stuefe at gmail.com Thu Oct 26 07:39:17 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Oct 2017 09:39:17 +0200 Subject: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image In-Reply-To: <5c0ef56a3c1a4c15822f05f84f1e0613@sap.com> References: <5c0ef56a3c1a4c15822f05f84f1e0613@sap.com> Message-ID: Hi Matthias, good job, thanks (and thanks to Magnus)! Just tried it, works. Change looks good. ..Thomas On Thu, Oct 26, 2017 at 9:05 AM, Baesken, Matthias wrote: > Hello , could you please review and push this small change fixing the > aix jre generation in jdk10 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ > > > (and later on it would be good to get it into jdk9 as well because the > same issue exists there too) > > Thanks and best regards, Matthias > > > > -----Original Message----- > > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > > Sent: Mittwoch, 25. Oktober 2017 16:46 > > To: Erik Joelsson ; Baesken, Matthias > > ; Thomas St?fe > > Cc: build-dev (build-dev at openjdk.java.net) ; > > ppc-aix-port-dev at openjdk.java.net > > Subject: Re: AIX build not generating a jre image > > > > On 2017-10-25 15:21, Erik Joelsson wrote: > > > Ah, good find. I would argue that the correct fix is: > > > > > > jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) > > > jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) > > > > Yeah, good find Matthias! > > > > I agree with Erik's suggested fix. This is a bit of "how has this ever > > worked?!?". It turns out that our closed extensions are unconditionally > > adding targets to JRE_TARGETS, so we never noticed that it could happen > > that JRE_TARGETS are empty, and the building of the JRE image does not > > work. This will happen on Windows as well as AIX. > > > > /Magnus > > > > > > > > /Erik > > > > > > On 2017-10-25 14:57, Baesken, Matthias wrote: > > >> Hi Magnus, thanks for your advice. > > >> Adding a bit of tracing to Images.gmk indeed helps to clarify the > > >> issue . > > >> Output of $(info this is the jre location: > > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) looks nice and as > > expected > > >> on AIX . > > >> However it turns out the $(JRE_TARGETS) was empty on AIX , > > >> this leads to an empty dependency > > >> > > >> jre: $(JRE_TARGETS) > > >> > > >> on AIX in Images.gmk , and this leads to ?Nothing to be done for ?. > ?. > > >> Background is that aix was not considered in the platform > > >> dependent parts of make/Images.gmk where JRE_TARGETS is filled > > >> for linux, macosx, solaris. > > >> I added aix there and the jre shows up in the images. > > >> Here is my diff (openjdk9) , still with tracing output AND with > > >> the added aix . > > >> Now JRE_TARGETS is not empty anymore which leads to successful > > >> generation of the JRE. > > >> > > >> Tracing output seen in the makefile > > >> + echo JRE_TARGETS are: > > /mygenerationdir/images/jre/man/man1/java.1 ?. > > >> > > >> > > >> Diff with tracing : > > >> > > >> diff -r a08cbfc0e4ec make/Images.gmk > > >> --- a/make/Images.gmk Thu Aug 03 18:56:56 2017 +0000 > > >> +++ b/make/Images.gmk Wed Oct 25 14:41:06 2017 +0200 > > >> @@ -43,6 +43,10 @@ > > >> $(eval $(call ReadImportMetaData)) > > >> +# helpful tracing > > >> +$(info this is the jre location: > > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > > >> + > > >> + > > >> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ > > >> $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) > > >> JDK_MODULES += $(ALL_MODULES) > > >> @@ -295,7 +299,7 @@ > > >> $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, > > >> $(JDK_MAN_PAGES)) > > >> endif > > >> - ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) > > >> + ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) > > >> JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, > > >> $(JRE_MAN_PAGES)) \ > > >> $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, > > >> $(JRE_MAN_PAGES)) \ > > >> $(JRE_IMAGE_DIR)/man/ja > > >> @@ -436,6 +440,8 @@ > > >> jdk: $(JDK_TARGETS) > > >> jre: $(JRE_TARGETS) > > >> + echo JRE_TARGETS are: $(JRE_TARGETS) , TOOL_JRE_TARGETS are: > > >> $(TOOL_JRE_TARGETS) > > >> + > > >> symbols: $(SYMBOLS_TARGETS) > > >> > > >> > > >> Best regards, Matthias > > >> > > >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > > >> Sent: Mittwoch, 25. Oktober 2017 10:24 > > >> To: Baesken, Matthias ; Thomas St?fe > > >> > > >> Cc: build-dev (build-dev at openjdk.java.net) > > >> ; ppc-aix-port-dev at openjdk.java.net > > >> Subject: Re: AIX build not generating a jre image > > >> > > >> > > >> On 2017-10-24 16:44, Baesken, Matthias wrote: > > >> > > >> * Do you get to this stage at all? I.e, can you see "Createing > > >> jre jimage" in the output? > > >> > > >> Hi Magnus, when comparing the linux and aix logs of our openjdk9 > > >> builds , I see for Linux at some point : > > >> > > >> > > >> > > >> gmake[3]: Entering directory ` . . . /nightly/jdk9/make' > > >> > > >> /bin/echo Creating jre jimage > > >> > > >> > > >> While on AIX it says : > > >> > > >> > > >> make[3]: Entering directory ` . . . /nightly/jdk9/make' > > >> > > >> make[3]: Nothing to be done for `jre'. > > >> > > >> make[3]: Leaving directory ` . . . /nightly/jdk9/make' > > >> > > >> > > >> this Looks wrong to me ! > > >> That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is > > considered > > >> up to date by make. This is wrong if that file does not exist. Are > > >> you *sure* you do not have a jre built? > > >> Verify the contents of these variables. Perhaps add a > > >> $(info this is the jre location: > > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > > >> at the top of Images.gmk, > > >> and check the location that is printed. > > >> > > >> /Magnus > > >> > > >> > > >> > > >> > > >> ( the . . . in the output has been removed by me it points to > > >> the build dir). > > >> > > >> Best regards, Matthias > > >> > > >> > > >> From: ppc-aix-port-dev > > >> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of > > >> Magnus Ihse Bursie > > >> Sent: Dienstag, 24. Oktober 2017 15:47 > > >> To: Thomas St?fe > > >> > > >> Cc: build-dev > > >> (build-dev at openjdk.java.net) > > >> ; > > >> ppc-aix-port-dev at openjdk.java.net > dev at openjdk.java.net> > > >> > > >> Subject: Re: AIX build not generating a jre image > > >> > > >> On 2017-10-23 10:16, Thomas St?fe wrote: > > >> Hi Magnus, > > >> > > >> On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > > >> > > > > > > > >> wrote: > > >> > > >> On 2017-10-18 16:14, Thomas St?fe wrote: > > >> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > > >> > > > >> 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. > > >> Since I don't have access to any AIX machines, it's difficult to for > > >> me to do much about this. Let me know if you need assistance in > > >> tracking this down. > > >> > > >> Some suggestions: > > >> run "make LOG=info,cmdlines" to track the progress of the build. > > >> > > >> If you get lost in the log files, try running "make jre-image" and > > >> then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines > > >> jre-image" to see only the output for the jre-image target. > > >> > > >> Thanks for the hints! I'll try that. I played around last week with > > >> make -d --print-data-base but got lost in the information. > > >> > > >> Last week I burned some time on this problem without much success. I > > >> got stuck understanding the rule in Images.gmk: > > >> > > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > > >> $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > > >> $(ECHO) Creating jre jimage > > >> $(RM) -r $(JRE_IMAGE_DIR) > > >> $(JLINK_JRE_EXTRA_OPTS) \ > > >> $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > > >> --output $(JRE_IMAGE_DIR) > > >> $(TOUCH) $@ > > >> > > >> and its brethren. > > >> > > >> It seems this rule just does not get executed for jre-image. So, > > >> trying to understand this (I am no makefile expert): > > >> > > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target > > >> dir, in this case jre/java, whose non-existence or out-of-dateness > > >> triggers the rule > > >> > > >> Dependencies: > > >> - $(JMODS) is /jmods, which gets built and does exist > > >> - $(call DependOnVariable, JRE_MODULES_LIST) > > >> This is just a macro that creates a dependency on the contents of the > > >> variable JRE_MODULES_LIST. > > >> > > >> > > >> > > >> $(BASE_RELEASE_FILE) is a text file which, if it exists and it > > >> contains the value of $JRE_MODULES_LIST, will result false (not out > > >> of date), otherwise it will update the file with the value of > > >> $JRE_MODULES_LIST and return true, triggering the target, yes? If I > > >> got this right, why do we use the same output file for all targets > > >> (jre, jdk) etc? > > >> No, this is a separate dependency. It's the file named "release" in > > >> the image that is to be included. If it has changed we need to > > >> trigger a new image. > > >> > > >> Do you get to this stage at all? I.e, can you see "Createing jre > > >> jimage" in the output? If not, there's a problem before we even get > > >> to this rule. Otherwise, the jlink command is likely broken. Try > > >> copy-pasting the full jlink command and running it from the shell > > >> directly to see what happens. > > >> > > >> /Magnus > > >> > > >> > > >> > > >> ..Thomas > > >> > > >> > > >> > > >> /Magnus > > >> > > >> > > >> > > >> > > >> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track > > >> this. > > >> > > >> ..Thomas > > >> > > >> > > >> > > >> > > >> Lindenmaier, Goetz > > >> > > > 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 at openjdk.java.net] On > > Behalf > > >> Of Steve Groeger > > >> Sent: Mittwoch, 18. Oktober 2017 14:34 > > >> To: > > >> ppc-aix-port-dev at openjdk.java.net > dev at 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 at 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 > > >> > > >> > > >> > > >> > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Oct 26 07:40:10 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Oct 2017 09:40:10 +0200 Subject: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image In-Reply-To: References: <5c0ef56a3c1a4c15822f05f84f1e0613@sap.com> Message-ID: (I'll push it) On Thu, Oct 26, 2017 at 9:39 AM, Thomas St?fe wrote: > Hi Matthias, > > good job, thanks (and thanks to Magnus)! > > Just tried it, works. > > Change looks good. > > ..Thomas > > > On Thu, Oct 26, 2017 at 9:05 AM, Baesken, Matthias < > matthias.baesken at sap.com> wrote: > >> Hello , could you please review and push this small change fixing the >> aix jre generation in jdk10 : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ >> >> >> (and later on it would be good to get it into jdk9 as well because the >> same issue exists there too) >> >> Thanks and best regards, Matthias >> >> >> > -----Original Message----- >> > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >> > Sent: Mittwoch, 25. Oktober 2017 16:46 >> > To: Erik Joelsson ; Baesken, Matthias >> > ; Thomas St?fe >> > Cc: build-dev (build-dev at openjdk.java.net) > >; >> > ppc-aix-port-dev at openjdk.java.net >> > Subject: Re: AIX build not generating a jre image >> > >> > On 2017-10-25 15:21, Erik Joelsson wrote: >> > > Ah, good find. I would argue that the correct fix is: >> > > >> > > jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) >> > > jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) >> > >> > Yeah, good find Matthias! >> > >> > I agree with Erik's suggested fix. This is a bit of "how has this ever >> > worked?!?". It turns out that our closed extensions are unconditionally >> > adding targets to JRE_TARGETS, so we never noticed that it could happen >> > that JRE_TARGETS are empty, and the building of the JRE image does not >> > work. This will happen on Windows as well as AIX. >> > >> > /Magnus >> > >> > > >> > > /Erik >> > > >> > > On 2017-10-25 14:57, Baesken, Matthias wrote: >> > >> Hi Magnus, thanks for your advice. >> > >> Adding a bit of tracing to Images.gmk indeed helps to clarify the >> > >> issue . >> > >> Output of $(info this is the jre location: >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) looks nice and as >> > expected >> > >> on AIX . >> > >> However it turns out the $(JRE_TARGETS) was empty on AIX , >> > >> this leads to an empty dependency >> > >> >> > >> jre: $(JRE_TARGETS) >> > >> >> > >> on AIX in Images.gmk , and this leads to ?Nothing to be done for >> ?. ?. >> > >> Background is that aix was not considered in the platform >> > >> dependent parts of make/Images.gmk where JRE_TARGETS is filled >> > >> for linux, macosx, solaris. >> > >> I added aix there and the jre shows up in the images. >> > >> Here is my diff (openjdk9) , still with tracing output AND with >> > >> the added aix . >> > >> Now JRE_TARGETS is not empty anymore which leads to successful >> > >> generation of the JRE. >> > >> >> > >> Tracing output seen in the makefile >> > >> + echo JRE_TARGETS are: >> > /mygenerationdir/images/jre/man/man1/java.1 ?. >> > >> >> > >> >> > >> Diff with tracing : >> > >> >> > >> diff -r a08cbfc0e4ec make/Images.gmk >> > >> --- a/make/Images.gmk Thu Aug 03 18:56:56 2017 +0000 >> > >> +++ b/make/Images.gmk Wed Oct 25 14:41:06 2017 +0200 >> > >> @@ -43,6 +43,10 @@ >> > >> $(eval $(call ReadImportMetaData)) >> > >> +# helpful tracing >> > >> +$(info this is the jre location: >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) >> > >> + >> > >> + >> > >> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ >> > >> $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) >> > >> JDK_MODULES += $(ALL_MODULES) >> > >> @@ -295,7 +299,7 @@ >> > >> $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, >> > >> $(JDK_MAN_PAGES)) >> > >> endif >> > >> - ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) >> > >> + ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) >> > >> JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, >> > >> $(JRE_MAN_PAGES)) \ >> > >> $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, >> > >> $(JRE_MAN_PAGES)) \ >> > >> $(JRE_IMAGE_DIR)/man/ja >> > >> @@ -436,6 +440,8 @@ >> > >> jdk: $(JDK_TARGETS) >> > >> jre: $(JRE_TARGETS) >> > >> + echo JRE_TARGETS are: $(JRE_TARGETS) , TOOL_JRE_TARGETS are: >> > >> $(TOOL_JRE_TARGETS) >> > >> + >> > >> symbols: $(SYMBOLS_TARGETS) >> > >> >> > >> >> > >> Best regards, Matthias >> > >> >> > >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >> > >> Sent: Mittwoch, 25. Oktober 2017 10:24 >> > >> To: Baesken, Matthias ; Thomas St?fe >> > >> >> > >> Cc: build-dev (build-dev at openjdk.java.net) >> > >> ; ppc-aix-port-dev at openjdk.java.net >> > >> Subject: Re: AIX build not generating a jre image >> > >> >> > >> >> > >> On 2017-10-24 16:44, Baesken, Matthias wrote: >> > >> >> > >> * Do you get to this stage at all? I.e, can you see "Createing >> > >> jre jimage" in the output? >> > >> >> > >> Hi Magnus, when comparing the linux and aix logs of our openjdk9 >> > >> builds , I see for Linux at some point : >> > >> >> > >> >> > >> >> > >> gmake[3]: Entering directory ` . . . /nightly/jdk9/make' >> > >> >> > >> /bin/echo Creating jre jimage >> > >> >> > >> >> > >> While on AIX it says : >> > >> >> > >> >> > >> make[3]: Entering directory ` . . . /nightly/jdk9/make' >> > >> >> > >> make[3]: Nothing to be done for `jre'. >> > >> >> > >> make[3]: Leaving directory ` . . . /nightly/jdk9/make' >> > >> >> > >> >> > >> this Looks wrong to me ! >> > >> That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is >> > considered >> > >> up to date by make. This is wrong if that file does not exist. Are >> > >> you *sure* you do not have a jre built? >> > >> Verify the contents of these variables. Perhaps add a >> > >> $(info this is the jre location: >> > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) >> > >> at the top of Images.gmk, >> > >> and check the location that is printed. >> > >> >> > >> /Magnus >> > >> >> > >> >> > >> >> > >> >> > >> ( the . . . in the output has been removed by me it points to >> > >> the build dir). >> > >> >> > >> Best regards, Matthias >> > >> >> > >> >> > >> From: ppc-aix-port-dev >> > >> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >> > >> Magnus Ihse Bursie >> > >> Sent: Dienstag, 24. Oktober 2017 15:47 >> > >> To: Thomas St?fe >> > >> >> > >> Cc: build-dev >> > >> (build-dev at openjdk.java.net) >> > >> ; >> > >> ppc-aix-port-dev at openjdk.java.net> > dev at openjdk.java.net> >> > >> >> > >> Subject: Re: AIX build not generating a jre image >> > >> >> > >> On 2017-10-23 10:16, Thomas St?fe wrote: >> > >> Hi Magnus, >> > >> >> > >> On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie >> > >> >> > >> > > >> > >> wrote: >> > >> >> > >> On 2017-10-18 16:14, Thomas St?fe wrote: >> > >> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis >> > >> > >> > >> 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. >> > >> Since I don't have access to any AIX machines, it's difficult to for >> > >> me to do much about this. Let me know if you need assistance in >> > >> tracking this down. >> > >> >> > >> Some suggestions: >> > >> run "make LOG=info,cmdlines" to track the progress of the build. >> > >> >> > >> If you get lost in the log files, try running "make jre-image" and >> > >> then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines >> > >> jre-image" to see only the output for the jre-image target. >> > >> >> > >> Thanks for the hints! I'll try that. I played around last week with >> > >> make -d --print-data-base but got lost in the information. >> > >> >> > >> Last week I burned some time on this problem without much success. I >> > >> got stuck understanding the rule in Images.gmk: >> > >> >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ >> > >> $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) >> > >> $(ECHO) Creating jre jimage >> > >> $(RM) -r $(JRE_IMAGE_DIR) >> > >> $(JLINK_JRE_EXTRA_OPTS) \ >> > >> $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ >> > >> --output $(JRE_IMAGE_DIR) >> > >> $(TOUCH) $@ >> > >> >> > >> and its brethren. >> > >> >> > >> It seems this rule just does not get executed for jre-image. So, >> > >> trying to understand this (I am no makefile expert): >> > >> >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target >> > >> dir, in this case jre/java, whose non-existence or out-of-dateness >> > >> triggers the rule >> > >> >> > >> Dependencies: >> > >> - $(JMODS) is /jmods, which gets built and does exist >> > >> - $(call DependOnVariable, JRE_MODULES_LIST) >> > >> This is just a macro that creates a dependency on the contents of the >> > >> variable JRE_MODULES_LIST. >> > >> >> > >> >> > >> >> > >> $(BASE_RELEASE_FILE) is a text file which, if it exists and it >> > >> contains the value of $JRE_MODULES_LIST, will result false (not out >> > >> of date), otherwise it will update the file with the value of >> > >> $JRE_MODULES_LIST and return true, triggering the target, yes? If I >> > >> got this right, why do we use the same output file for all targets >> > >> (jre, jdk) etc? >> > >> No, this is a separate dependency. It's the file named "release" in >> > >> the image that is to be included. If it has changed we need to >> > >> trigger a new image. >> > >> >> > >> Do you get to this stage at all? I.e, can you see "Createing jre >> > >> jimage" in the output? If not, there's a problem before we even get >> > >> to this rule. Otherwise, the jlink command is likely broken. Try >> > >> copy-pasting the full jlink command and running it from the shell >> > >> directly to see what happens. >> > >> >> > >> /Magnus >> > >> >> > >> >> > >> >> > >> ..Thomas >> > >> >> > >> >> > >> >> > >> /Magnus >> > >> >> > >> >> > >> >> > >> >> > >> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track >> > >> this. >> > >> >> > >> ..Thomas >> > >> >> > >> >> > >> >> > >> >> > >> Lindenmaier, Goetz >> > >> > >> > 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 at openjdk.java.net] On >> > Behalf >> > >> Of Steve Groeger >> > >> Sent: Mittwoch, 18. Oktober 2017 14:34 >> > >> To: >> > >> ppc-aix-port-dev at openjdk.java.net> > dev at 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 at 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 >> > >> >> > >> >> > >> >> > >> >> > >> >> > > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: