From vyom.tewari at oracle.com Thu Jun 1 04:15:08 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Thu, 1 Jun 2017 09:45:08 +0530 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: References: Message-ID: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Hi Thomas, one minor comment apart from what Christoph gave, you can combine the the two explicit assignment statements to one in all three places. rv = (jlong)sb.st_mtimespec.tv_sec * 1000; rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; to rv= (jlong)sb.st_mtimespec.tv_sec * 1000 +(jlong)sb.st_mtimespec.tv_nsec / 1000000; Thanks, Vyom On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: > Hi Volker, > > Good suggestions! I completely overlooked the ..._n members in stat64 > struct. It seems it is even documented: > https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm > > new webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/ > > ..Thomas > > On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > wrote: > >> Hi Thomas, >> >> as far as I can see, AIX supports both, the st_[a,c,m]time members in >> the stat64 structure for seconds and the corresponding >> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. >> Can you please use both - there's no reason to discriminate AIX here >> :) >> >> Also, can you please change the code such that we have: >> >> #ifdef MACOSX >> ... >> #else >> #ifdef AIX >> ... >> #else >> ... >> #endif >> #endif >> >> I don't really like using "ifndef XXX" for everything else except XXX. >> >> Thnank you and best regards, >> Volker >> >> >> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe >> wrote: >>> Hi all, >>> >>> may I have please a review for this tiny change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- >> 8177809-breaks-AIX-builds/webrev.00/webrev/ >>> This reverts 8177809 for AIX because it leads to build errors on older >> AIX >>> systems. We want to retain the ability to build on older AIX releases. >>> >>> Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jun 1 06:13:05 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 08:13:05 +0200 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> References: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Message-ID: Okay, last webrev, added Christoph' suggestions of reformulating the #ifdef chain. http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.02/webrev/ @Vyom: I'd rather keep the expression like it is to match the other platforms. Guys, lets get this in, this is a simple build fix :) On Thu, Jun 1, 2017 at 6:15 AM, Vyom Tewari wrote: > Hi Thomas, > > one minor comment apart from what Christoph gave, you can combine the the > two explicit assignment statements to one in all three places. > > rv = (jlong)sb.st_mtimespec.tv_sec * 1000; > > rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; > > to > rv= (jlong)sb.st_mtimespec.tv_sec * 1000 + (jlong)sb.st_mtimespec.tv_nsec / 1000000; > > Thanks, > Vyom > > > On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: > > Hi Volker, > > Good suggestions! I completely overlooked the ..._n members in stat64 > struct. It seems it is even documented:https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm > > new webrev:http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/ > > ..Thomas > > On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > wrote: > > > Hi Thomas, > > as far as I can see, AIX supports both, the st_[a,c,m]time members in > the stat64 structure for seconds and the corresponding > st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. > Can you please use both - there's no reason to discriminate AIX here > :) > > Also, can you please change the code such that we have: > > #ifdef MACOSX > ... > #else > #ifdef AIX > ... > #else > ... > #endif > #endif > > I don't really like using "ifndef XXX" for everything else except XXX. > > Thnank you and best regards, > Volker > > > On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe > wrote: > > Hi all, > > may I have please a review for this tiny change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 > webrev:http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > > 8177809-breaks-AIX-builds/webrev.00/webrev/ > > This reverts 8177809 for AIX because it leads to build errors on older > > AIX > > systems. We want to retain the ability to build on older AIX releases. > > Thanks, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Jun 1 06:47:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 1 Jun 2017 08:47:45 +0200 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: References: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Message-ID: Hi Thomas, the change looks good now. I think the comment about "AIX 5.3 backward compatibility" isn't strictly needed, but I leave it up to you (anyhow you decide, there's no need for a new webrev). Feel free to push it. Thanks, Volker On Thu, Jun 1, 2017 at 8:13 AM, Thomas St?fe wrote: > Okay, last webrev, added Christoph' suggestions of reformulating the #ifdef > chain. > > http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.02/webrev/ > > @Vyom: I'd rather keep the expression like it is to match the other > platforms. > > Guys, lets get this in, this is a simple build fix :) > > On Thu, Jun 1, 2017 at 6:15 AM, Vyom Tewari wrote: >> >> Hi Thomas, >> >> one minor comment apart from what Christoph gave, you can combine the the >> two explicit assignment statements to one in all three places. >> >> rv = (jlong)sb.st_mtimespec.tv_sec * 1000; >> >> rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; >> >> to >> rv= (jlong)sb.st_mtimespec.tv_sec * 1000 + (jlong)sb.st_mtimespec.tv_nsec >> / 1000000; >> >> Thanks, >> Vyom >> >> >> On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: >> >> Hi Volker, >> >> Good suggestions! I completely overlooked the ..._n members in stat64 >> struct. It seems it is even documented: >> >> https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm >> >> new webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/ >> >> ..Thomas >> >> On Wed, May 31, 2017 at 10:49 AM, Volker Simonis >> >> wrote: >> >> Hi Thomas, >> >> as far as I can see, AIX supports both, the st_[a,c,m]time members in >> the stat64 structure for seconds and the corresponding >> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. >> Can you please use both - there's no reason to discriminate AIX here >> :) >> >> Also, can you please change the code such that we have: >> >> #ifdef MACOSX >> ... >> #else >> #ifdef AIX >> ... >> #else >> ... >> #endif >> #endif >> >> I don't really like using "ifndef XXX" for everything else except XXX. >> >> Thnank you and best regards, >> Volker >> >> >> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe >> wrote: >> >> Hi all, >> >> may I have please a review for this tiny change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- >> >> 8177809-breaks-AIX-builds/webrev.00/webrev/ >> >> This reverts 8177809 for AIX because it leads to build errors on older >> >> AIX >> >> systems. We want to retain the ability to build on older AIX releases. >> >> Thanks, Thomas >> >> > From thomas.stuefe at gmail.com Thu Jun 1 06:50:19 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jun 2017 08:50:19 +0200 Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds In-Reply-To: References: <862813d3-bba3-d4ba-2d70-9f0232b74b8c@oracle.com> Message-ID: Thank you Volker! On Thu, Jun 1, 2017 at 8:47 AM, Volker Simonis wrote: > Hi Thomas, > > the change looks good now. I think the comment about "AIX 5.3 backward > compatibility" isn't strictly needed, but I leave it up to you (anyhow > you decide, there's no need for a new webrev). Feel free to push it. > > Thanks, > Volker > > > On Thu, Jun 1, 2017 at 8:13 AM, Thomas St?fe > wrote: > > Okay, last webrev, added Christoph' suggestions of reformulating the > #ifdef > > chain. > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > 8177809-breaks-AIX-builds/webrev.02/webrev/ > > > > @Vyom: I'd rather keep the expression like it is to match the other > > platforms. > > > > Guys, lets get this in, this is a simple build fix :) > > > > On Thu, Jun 1, 2017 at 6:15 AM, Vyom Tewari > wrote: > >> > >> Hi Thomas, > >> > >> one minor comment apart from what Christoph gave, you can combine the > the > >> two explicit assignment statements to one in all three places. > >> > >> rv = (jlong)sb.st_mtimespec.tv_sec * 1000; > >> > >> rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; > >> > >> to > >> rv= (jlong)sb.st_mtimespec.tv_sec * 1000 + > (jlong)sb.st_mtimespec.tv_nsec > >> / 1000000; > >> > >> Thanks, > >> Vyom > >> > >> > >> On Wednesday 31 May 2017 08:59 PM, Thomas St?fe wrote: > >> > >> Hi Volker, > >> > >> Good suggestions! I completely overlooked the ..._n members in stat64 > >> struct. It seems it is even documented: > >> > >> https://www.ibm.com/support/knowledgecenter/ssw_aix_72/ > com.ibm.aix.files/stat.h.htm > >> > >> new webrev: > >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > 8177809-breaks-AIX-builds/webrev.01/webrev/ > >> > >> ..Thomas > >> > >> On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > >> > >> wrote: > >> > >> Hi Thomas, > >> > >> as far as I can see, AIX supports both, the st_[a,c,m]time members in > >> the stat64 structure for seconds and the corresponding > >> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3. > >> Can you please use both - there's no reason to discriminate AIX here > >> :) > >> > >> Also, can you please change the code such that we have: > >> > >> #ifdef MACOSX > >> ... > >> #else > >> #ifdef AIX > >> ... > >> #else > >> ... > >> #endif > >> #endif > >> > >> I don't really like using "ifndef XXX" for everything else except XXX. > >> > >> Thnank you and best regards, > >> Volker > >> > >> > >> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe > > >> wrote: > >> > >> Hi all, > >> > >> may I have please a review for this tiny change: > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207 > >> webrev: > >> http://cr.openjdk.java.net/~stuefe/webrevs/8181207- > >> > >> 8177809-breaks-AIX-builds/webrev.00/webrev/ > >> > >> This reverts 8177809 for AIX because it leads to build errors on older > >> > >> AIX > >> > >> systems. We want to retain the ability to build on older AIX releases. > >> > >> Thanks, Thomas > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From HORIE at jp.ibm.com Fri Jun 2 09:28:01 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Fri, 2 Jun 2017 17:28:01 +0800 Subject: 8179527: Implement intrinsic code for reverseBytes with load/store In-Reply-To: References: <3507c10563a84106ac6c2e8d2554c053@serv030.corp.eldorado.org.br> <7827421e2c6447f4ae406434f5bb3d25@sap.com> <552ec8649cfb48ccaf01ef7b238c0711@sap.com> Message-ID: Volker, Thank you very much for the 2nd review. Attached includes micro benchmarks I used for the verification. (See attached file: reverseBytesBench.tar.gz) Best regards, -- Michihiro, IBM Research - Tokyo From: Volker Simonis To: "Doerr, Martin" Cc: Michihiro Horie , Gustavo Bueno Romero , Hiroshi H Horii , "hotspot-dev at openjdk.java.net" Date: 2017/06/02 17:04 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review Martin :) I'm just wondering if you had some test-cases to verify if the new nodes really match? Change looks good now. Regards, Volker On Thu, Jun 1, 2017 at 6:00 PM, Doerr, Martin wrote: Hi Michihiro, thank you very much for providing the new webrev (with support for older Power processors, which was missing in webrev.02): http://cr.openjdk.java.net/~horii/8179527/webrev.03/ I have built and executed the VM on a Power6 machine. Thanks for supporting it. I would have spent only one flag for has_ldbrx/has_stdbrx, but I?m ok with it. The change looks good to me and I will sponsor it after 2nd review. Best regards, Martin From: Doerr, Martin Sent: Mittwoch, 31. Mai 2017 15:54 To: 'Michihiro Horie' ; Volker Simonis ( volker.simonis at gmail.com) Cc: Gustavo Bueno Romero ; Hiroshi H Horii < HORII at jp.ibm.com>; hotspot-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thank you for the new webrev with all of my suggestions. Looks good to me. There?s only a trailing whitespace which I had to remove to satisfy ?hg jcheck? (otherwise push attempt would get rejected). We?ll run tests. Maybe we can get a 2nd review in the meantime? Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 31. Mai 2017 14:36 To: Doerr, Martin Cc: Gustavo Bueno Romero ; Hiroshi H Horii < HORII at jp.ibm.com>; hotspot-dev at openjdk.java.net; Simonis, Volker < volker.simonis at sap.com>; ppc-aix-port-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Martin, Thank you very much for your helpful comments and sponsoring this change. Would you review the latest change? http://cr.openjdk.java.net/~horii/8179527/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks bet"Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of sugges From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" , "Simonis, Volker" , Hiroshi H Horii < HORII at jp.ibm.com>, Gustavo Bueno Romero Date: 2017/05/30 01:26 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of suggestions. 1. I still don?t like match rules which contain nodes which do something else (even though direct matching is prohibited by predicate). I think it would be better to remove ?match(?)?, ?predicate(false)? and ?ins_const(?)? and just describe the ?effect()?. At least, I?m not aware of why a match rule should be needed for rldicl and extsh. 2. I?d appreciate if you could remove ?predicate (UseCountLeadingZerosInstructionsPPC64)? from all byte_reverse_... rules. They don?t make any sense (not your fault). 3. The costs seem not to be set appropriately in the byte_reverse_... rules. E.g. instruction count * DEFAULT_COST would be better. 4. The load/store byte reversed instructions should use the 2 operand form (no explicit 0 for R0 to support assertions). Maybe we can find a 2nd reviewer if you provide a new webrev. I can sponsor the change. Thanks and best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 8. Mai 2017 06:58 To: Doerr, Martin ; Lindenmaier, Goetz < goetz.lindenmaier at sap.com> Cc: Gustavo Serra Scalet ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Hiroshi H Horii ; Gustavo Bueno Romero Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Dear Martin, Gustavo, Thank you very much for your helpful comments. Fixed code is http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Dear Goetz, Would you kindly review and sponsor this change? I heard you are a C2 compiler expert and Martin is out for a while. Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementi"Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementing this change. From: "Doerr, Martin" To: Gustavo Serra Scalet , Michihiro Horie/Japan/IBM at IBMJP Cc: "ppc-aix-port-dev at openjdk.java.net" < ppc-aix-port-dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net" < hotspot-dev at openjdk.java.net>, "Simonis, Volker" Date: 2017/05/03 02:24 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro and Gustavo, thank you very much for implementing this change. @Gustavo: Thanks for taking a look. I think that the direct match rules are just there to satisfy match_rule_supported. They don't need to be fast, they are just a fall back solution. The goal is to exploit the byte reverse load and store instructions which should match in more performance critical cases. Now my review: assembler_ppc.hpp: Looks good except a minor formatting request: LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532 << 1), should be LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532u << 1), to be consistent. The comments // X-FORM should be aligned with the other ones. assembler_ppc.inline.hpp: Good. ppc.ad: I'm concerned about the additional match rules which are only used for the expand step. They could match directly leading to incorrect code. What they match is not what they do. I suggest to implement the code directly in the ins_encode. This would make the new code significantly shorter and less error prone. I think we don't need to optimize for Power6 anymore and newer processors shouldn't really suffer under a little less optimized instruction scheduling. Would you agree? Displacements may be too large for "li" so I suggest to use the "indirect" memory operand and let the compiler handle it. I know that it may increase latency because the compiler will need to insert an addition which could better be matched into the memory operand of the load which is harder to implement (it is possible to match an addition in an operand). Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Dienstag, 2. Mai 2017 17:05 To: Michihiro Horie Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Simonis, Volker ; Doerr, Martin < martin.doerr at sap.com> Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, I wonder if there is no vectorized approach for implementing your "bytes_reverse_long_Ex" instruct on ppc.ad. Or did you avoid doing it so intentionally? > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Michihiro Horie > Sent: ter?a-feira, 2 de maio de 2017 11:47 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > volker.simonis at sap.com; martin.doerr at sap.com > Subject: 8179527: Implement intrinsic code for reverseBytes with > load/store > > Dear all, > > Would you please review following change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179527 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > I added new intrinsic code for reverseBytes() in ppc.ad with > * match(Set dst (ReverseBytesI/L/US/S (LoadI src))); > * match(Set dst (StoreI dst (ReverseBytesI/L/US/S src))); > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: reverseBytesBench.tar.gz Type: application/octet-stream Size: 1714 bytes Desc: not available URL: From volker.simonis at gmail.com Fri Jun 2 12:11:17 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 2 Jun 2017 14:11:17 +0200 Subject: 8179527: Implement intrinsic code for reverseBytes with load/store In-Reply-To: References: <3507c10563a84106ac6c2e8d2554c053@serv030.corp.eldorado.org.br> <7827421e2c6447f4ae406434f5bb3d25@sap.com> <552ec8649cfb48ccaf01ef7b238c0711@sap.com> Message-ID: Hi Michihiro, thanks a lot for providing your micro-benchmarks. So, did you use PrintAssemby/PrintOtpoAssembly to verify that the new nodes are matched? Regards, Volker On Fri, Jun 2, 2017 at 11:28 AM, Michihiro Horie wrote: > Volker, > > Thank you very much for the 2nd review. > Attached includes micro benchmarks I used for the verification. > *(See attached file: reverseBytesBench.tar.gz)* > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > [image: Inactive hide details for Volker Simonis ---2017/06/02 > 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro a]Volker > Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the > change Michihiro and thanks for the thorough review > > From: Volker Simonis > To: "Doerr, Martin" > Cc: Michihiro Horie , Gustavo Bueno Romero < > gromero at br.ibm.com>, Hiroshi H Horii , " > hotspot-dev at openjdk.java.net" > Date: 2017/06/02 17:04 > Subject: Re: 8179527: Implement intrinsic code for reverseBytes with > load/store > > ------------------------------ > > > > Hi Michihiro, Martin, > > thanks a lot for the change Michihiro and thanks for the thorough review > Martin :) > > I'm just wondering if you had some test-cases to verify if the new nodes > really match? > > Change looks good now. > > Regards, > Volker > > > On Thu, Jun 1, 2017 at 6:00 PM, Doerr, Martin <*martin.doerr at sap.com* > > wrote: > > Hi Michihiro, > > > > thank you very much for providing the new webrev (with support for > older Power processors, which was missing in webrev.02): > > *http://cr.openjdk.java.net/~horii/8179527/webrev.03/* > > > > > I have built and executed the VM on a Power6 machine. Thanks for > supporting it. > > I would have spent only one flag for has_ldbrx/has_stdbrx, but I?m ok > with it. The change looks good to me and I will sponsor it after 2nd > review. > > > > Best regards, > > Martin > > > > > > *From:* Doerr, Martin > * Sent:* Mittwoch, 31. Mai 2017 15:54 > * To:* 'Michihiro Horie' <*HORIE at jp.ibm.com* >; Volker > Simonis (*volker.simonis at gmail.com* ) < > *volker.simonis at gmail.com* > > * Cc:* Gustavo Bueno Romero <*gromero at br.ibm.com* >; > Hiroshi H Horii <*HORII at jp.ibm.com* >; > *hotspot-dev at openjdk.java.net* > > *Subject:* RE: 8179527: Implement intrinsic code for reverseBytes with > load/store > > > > Hi Michihiro, > > > > thank you for the new webrev with all of my suggestions. Looks good to > me. > > There?s only a trailing whitespace which I had to remove to satisfy > ?hg jcheck? (otherwise push attempt would get rejected). > > > > We?ll run tests. Maybe we can get a 2nd review in the meantime? > > > > Best regards, > > Martin > > > > > > *From:* Michihiro Horie [*mailto:HORIE at jp.ibm.com* ] > * Sent:* Mittwoch, 31. Mai 2017 14:36 > * To:* Doerr, Martin <*martin.doerr at sap.com* > > * Cc:* Gustavo Bueno Romero <*gromero at br.ibm.com* >; > Hiroshi H Horii <*HORII at jp.ibm.com* >; > *hotspot-dev at openjdk.java.net* ; > Simonis, Volker <*volker.simonis at sap.com* >; > *ppc-aix-port-dev at openjdk.java.net* > * Subject:* RE: 8179527: Implement intrinsic code for reverseBytes with > load/store > > > > Martin, > > Thank you very much for your helpful comments and sponsoring this > change. > > Would you review the latest change? > *http://cr.openjdk.java.net/~horii/8179527/webrev.02/* > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > [image: Inactive hide details for "Doerr, Martin" ---2017/05/30 > 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks bet]"Doerr, > Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved > webrev. This looks better, but I still have a couple of sugges > > From: "Doerr, Martin" <*martin.doerr at sap.com* > > To: Michihiro Horie <*HORIE at jp.ibm.com* > > Cc: "*hotspot-dev at openjdk.java.net* " < > *hotspot-dev at openjdk.java.net* >, > "Simonis, Volker" <*volker.simonis at sap.com* >, > Hiroshi H Horii <*HORII at jp.ibm.com* >, Gustavo Bueno > Romero <*gromero at br.ibm.com* > > Date: 2017/05/30 01:26 > Subject: RE: 8179527: Implement intrinsic code for reverseBytes with > load/store > > ------------------------------ > > > > > Hi Michihiro, > > thanks for the improved webrev. This looks better, but I still have a > couple of suggestions. > > 1. > I still don?t like match rules which contain nodes which do something > else (even though direct matching is prohibited by predicate). > I think it would be better to remove ?match(?)?, ?predicate(false)? > and ?ins_const(?)? and just describe the ?effect()?. At least, I?m not > aware of why a match rule should be needed for rldicl and extsh. > > 2. > I?d appreciate if you could remove ?predicate( > UseCountLeadingZerosInstructionsPPC64)? from all byte_reverse_... > rules. They don?t make any sense (not your fault). > > 3. > The costs seem not to be set appropriately in the byte_reverse_... > rules. E.g. instruction count * DEFAULT_COST would be better. > > 4. > The load/store byte reversed instructions should use the 2 operand > form (no explicit 0 for R0 to support assertions). > > Maybe we can find a 2nd reviewer if you provide a new webrev. I can > sponsor the change. > > Thanks and best regards, > Martin > > > * From:* Michihiro Horie [*mailto:HORIE at jp.ibm.com* ] > * Sent:* Montag, 8. Mai 2017 06:58 > * To:* Doerr, Martin <*martin.doerr at sap.com* >; > Lindenmaier, Goetz <*goetz.lindenmaier at sap.com* > > > * Cc:* Gustavo Serra Scalet <*gustavo.scalet at eldorado.org.br* > >; *hotspot-dev at openjdk.java.net* > ; *ppc-aix-port-dev at openjdk.java.net* > ; Simonis, Volker < > *volker.simonis at sap.com* >; Hiroshi H Horii < > *HORII at jp.ibm.com* >; Gustavo Bueno Romero < > *gromero at br.ibm.com* > > * Subject:* RE: 8179527: Implement intrinsic code for reverseBytes with > load/store > > Dear Martin, Gustavo, > > Thank you very much for your helpful comments. > > Fixed code is > *http://cr.openjdk.java.net/~horii/8179527/webrev.01/* > > > Dear Goetz, > Would you kindly review and sponsor this change? > I heard you are a C2 compiler expert and Martin is out for a while. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > [image: Inactive hide details for "Doerr, Martin" ---2017/05/03 > 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementi]"Doerr, > Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very > much for implementing this change. > > From: "Doerr, Martin" <*martin.doerr at sap.com* > > To: Gustavo Serra Scalet <*gustavo.scalet at eldorado.org.br* > >, Michihiro Horie/Japan/IBM at IBMJP > Cc: "*ppc-aix-port-dev at openjdk.java.net* > " < > *ppc-aix-port-dev at openjdk.java.net* >, > "*hotspot-dev at openjdk.java.net* " < > *hotspot-dev at openjdk.java.net* >, > "Simonis, Volker" <*volker.simonis at sap.com* > > Date: 2017/05/03 02:24 > Subject: RE: 8179527: Implement intrinsic code for reverseBytes with > load/store > > ------------------------------ > > > > > > Hi Michihiro and Gustavo, > > thank you very much for implementing this change. > > @Gustavo: Thanks for taking a look. > I think that the direct match rules are just there to satisfy > match_rule_supported. They don't need to be fast, they are just a fall back > solution. > The goal is to exploit the byte reverse load and store instructions > which should match in more performance critical cases. > > Now my review: > > assembler_ppc.hpp: > Looks good except a minor formatting request: > LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532 << 1), > should be > LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532u << 1), > to be consistent. > The comments // X-FORM should be aligned with the other ones. > > assembler_ppc.inline.hpp: > Good. > > *ppc.ad* : > I'm concerned about the additional match rules which are only used for > the expand step. They could match directly leading to incorrect code. What > they match is not what they do. > I suggest to implement the code directly in the ins_encode. This would > make the new code significantly shorter and less error prone. > I think we don't need to optimize for Power6 anymore and newer > processors shouldn't really suffer under a little less optimized > instruction scheduling. Would you agree? > > Displacements may be too large for "li" so I suggest to use the > "indirect" memory operand and let the compiler handle it. I know that it > may increase latency because the compiler will need to insert an addition > which could better be matched into the memory operand of the load which is > harder to implement (it is possible to match an addition in an operand). > > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [*mailto:gustavo.scalet at eldorado.org.br* > ] > Sent: Dienstag, 2. Mai 2017 17:05 > To: Michihiro Horie <*HORIE at jp.ibm.com* > > Cc: *ppc-aix-port-dev at openjdk.java.net* > ; *hotspot-dev at openjdk.java.net* > ; Simonis, Volker < > *volker.simonis at sap.com* >; Doerr, Martin < > *martin.doerr at sap.com* > > Subject: RE: 8179527: Implement intrinsic code for reverseBytes with > load/store > > Hi Michihiro, > > I wonder if there is no vectorized approach for implementing your > "bytes_reverse_long_Ex" instruct on *ppc.ad* . Or did > you avoid doing it so intentionally? > > > -----Original Message----- > > From: ppc-aix-port-dev [*mailto:ppc-aix-port-dev-* > > > *bounces at openjdk.java.net* ] On Behalf Of > Michihiro Horie > > Sent: ter?a-feira, 2 de maio de 2017 11:47 > > To: *ppc-aix-port-dev at openjdk.java.net* > ; *hotspot-dev at openjdk.java.net* > ; > > *volker.simonis at sap.com* ; > *martin.doerr at sap.com* > > Subject: 8179527: Implement intrinsic code for reverseBytes with > > load/store > > > > Dear all, > > > > Would you please review following change? > > > > Bug: *https://bugs.openjdk.java.net/browse/JDK-8179527* > > > Webrev: *http://cr.openjdk.java.net/~horii/8179527/webrev.00/* > > > > > I added new intrinsic code for reverseBytes() in *ppc.ad* > with > > * match(Set dst (ReverseBytesI/L/US/S (LoadI src))); > > * match(Set dst (StoreI dst (ReverseBytesI/L/US/S src))); > > > > > > 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 HORIE at jp.ibm.com Fri Jun 2 12:15:32 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Fri, 2 Jun 2017 20:15:32 +0800 Subject: 8179527: Implement intrinsic code for reverseBytes with load/store In-Reply-To: References: <3507c10563a84106ac6c2e8d2554c053@serv030.corp.eldorado.org.br> <7827421e2c6447f4ae406434f5bb3d25@sap.com> <552ec8649cfb48ccaf01ef7b238c0711@sap.com> Message-ID: Volker, I used OProfile's opannotate to verify the nodes are matched. Best regards, -- Michihiro, IBM Research - Tokyo From: Volker Simonis To: Michihiro Horie Cc: Gustavo Bueno Romero , Hiroshi H Horii , "hotspot-dev at openjdk.java.net" , "Doerr, Martin" , "ppc-aix-port-dev at openjdk.java.net" Date: 2017/06/02 20:11 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thanks a lot for providing your micro-benchmarks. So, did you use PrintAssemby/PrintOtpoAssembly to verify that the new nodes are matched? Regards, Volker On Fri, Jun 2, 2017 at 11:28 AM, Michihiro Horie wrote: Volker, Thank you very much for the 2nd review. Attached includes micro benchmarks I used for the verification. (See attached file: reverseBytesBench.tar.gz) Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for Volker Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro aVolker Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review From: Volker Simonis To: "Doerr, Martin" Cc: Michihiro Horie , Gustavo Bueno Romero < gromero at br.ibm.com>, Hiroshi H Horii , " hotspot-dev at openjdk.java.net" Date: 2017/06/02 17:04 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review Martin :) I'm just wondering if you had some test-cases to verify if the new nodes really match? Change looks good now. Regards, Volker On Thu, Jun 1, 2017 at 6:00 PM, Doerr, Martin wrote: Hi Michihiro, thank you very much for providing the new webrev (with support for older Power processors, which was missing in webrev.02): http://cr.openjdk.java.net/~horii/8179527/webrev.03/ I have built and executed the VM on a Power6 machine. Thanks for supporting it. I would have spent only one flag for has_ldbrx/has_stdbrx, but I?m ok with it. The change looks good to me and I will sponsor it after 2nd review. Best regards, Martin From: Doerr, Martin Sent: Mittwoch, 31. Mai 2017 15:54 To: 'Michihiro Horie' ; Volker Simonis ( volker.simonis at gmail.com) Cc: Gustavo Bueno Romero ; Hiroshi H Horii < HORII at jp.ibm.com>; hotspot-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thank you for the new webrev with all of my suggestions. Looks good to me. There?s only a trailing whitespace which I had to remove to satisfy ?hg jcheck? (otherwise push attempt would get rejected). We?ll run tests. Maybe we can get a 2nd review in the meantime? Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 31. Mai 2017 14:36 To: Doerr, Martin Cc: Gustavo Bueno Romero ; Hiroshi H Horii < HORII at jp.ibm.com>; hotspot-dev at openjdk.java.net; Simonis, Volker < volker.simonis at sap.com>; ppc-aix-port-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Martin, Thank you very much for your helpful comments and sponsoring this change. Would you review the latest change? http://cr.openjdk.java.net/~horii/8179527/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks bet"Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of sugges From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" , "Simonis, Volker" , Hiroshi H Horii < HORII at jp.ibm.com>, Gustavo Bueno Romero Date: 2017/05/30 01:26 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of suggestions. 1. I still don?t like match rules which contain nodes which do something else (even though direct matching is prohibited by predicate). I think it would be better to remove ?match(?)?, ?predicate(false)? and ?ins_const(?)? and just describe the ?effect()?. At least, I?m not aware of why a match rule should be needed for rldicl and extsh. 2. I?d appreciate if you could remove ?predicate (UseCountLeadingZerosInstructionsPPC64)? from all byte_reverse_... rules. They don?t make any sense (not your fault). 3. The costs seem not to be set appropriately in the byte_reverse_... rules. E.g. instruction count * DEFAULT_COST would be better. 4. The load/store byte reversed instructions should use the 2 operand form (no explicit 0 for R0 to support assertions). Maybe we can find a 2nd reviewer if you provide a new webrev. I can sponsor the change. Thanks and best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 8. Mai 2017 06:58 To: Doerr, Martin ; Lindenmaier, Goetz < goetz.lindenmaier at sap.com> Cc: Gustavo Serra Scalet ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Hiroshi H Horii < HORII at jp.ibm.com>; Gustavo Bueno Romero Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Dear Martin, Gustavo, Thank you very much for your helpful comments. Fixed code is http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Dear Goetz, Would you kindly review and sponsor this change? I heard you are a C2 compiler expert and Martin is out for a while. Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementi"Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementing this change. From: "Doerr, Martin" To: Gustavo Serra Scalet , Michihiro Horie/Japan/IBM at IBMJP Cc: "ppc-aix-port-dev at openjdk.java.net" < ppc-aix-port-dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net" , "Simonis, Volker" < volker.simonis at sap.com> Date: 2017/05/03 02:24 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro and Gustavo, thank you very much for implementing this change. @Gustavo: Thanks for taking a look. I think that the direct match rules are just there to satisfy match_rule_supported. They don't need to be fast, they are just a fall back solution. The goal is to exploit the byte reverse load and store instructions which should match in more performance critical cases. Now my review: assembler_ppc.hpp: Looks good except a minor formatting request: LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532 << 1), should be LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532u << 1), to be consistent. The comments // X-FORM should be aligned with the other ones. assembler_ppc.inline.hpp: Good. ppc.ad: I'm concerned about the additional match rules which are only used for the expand step. They could match directly leading to incorrect code. What they match is not what they do. I suggest to implement the code directly in the ins_encode. This would make the new code significantly shorter and less error prone. I think we don't need to optimize for Power6 anymore and newer processors shouldn't really suffer under a little less optimized instruction scheduling. Would you agree? Displacements may be too large for "li" so I suggest to use the "indirect" memory operand and let the compiler handle it. I know that it may increase latency because the compiler will need to insert an addition which could better be matched into the memory operand of the load which is harder to implement (it is possible to match an addition in an operand). Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Dienstag, 2. Mai 2017 17:05 To: Michihiro Horie Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net ; Simonis, Volker ; Doerr, Martin < martin.doerr at sap.com> Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, I wonder if there is no vectorized approach for implementing your "bytes_reverse_long_Ex" instruct on ppc.ad. Or did you avoid doing it so intentionally? > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Michihiro Horie > Sent: ter?a-feira, 2 de maio de 2017 11:47 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > volker.simonis at sap.com; martin.doerr at sap.com > Subject: 8179527: Implement intrinsic code for reverseBytes with > load/store > > Dear all, > > Would you please review following change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179527 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > I added new intrinsic code for reverseBytes() in ppc.ad with > * match(Set dst (ReverseBytesI/L/US/S (LoadI src))); > * match(Set dst (StoreI dst (ReverseBytesI/L/US/S src))); > > > 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 Fri Jun 2 14:39:03 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 2 Jun 2017 14:39:03 +0000 Subject: 8179527: Implement intrinsic code for reverseBytes with load/store In-Reply-To: References: <3507c10563a84106ac6c2e8d2554c053@serv030.corp.eldorado.org.br> <7827421e2c6447f4ae406434f5bb3d25@sap.com> <552ec8649cfb48ccaf01ef7b238c0711@sap.com> Message-ID: Hi Michihiro, thanks for providing the micro benchmarks. I have run some of them on Power6 as additional test. All testing was good and we have 2 reviews, so I?ve pushed it. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Freitag, 2. Juni 2017 14:16 To: Volker Simonis Cc: Gustavo Bueno Romero ; Hiroshi H Horii ; hotspot-dev at openjdk.java.net; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Volker, I used OProfile's opannotate to verify the nodes are matched. Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for Volker Simonis ---2017/06/02 20:11:22---Hi Michihiro, thanks a lot for providing your micro-benchmark]Volker Simonis ---2017/06/02 20:11:22---Hi Michihiro, thanks a lot for providing your micro-benchmarks. From: Volker Simonis > To: Michihiro Horie > Cc: Gustavo Bueno Romero >, Hiroshi H Horii >, "hotspot-dev at openjdk.java.net" >, "Doerr, Martin" >, "ppc-aix-port-dev at openjdk.java.net" > Date: 2017/06/02 20:11 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store ________________________________ Hi Michihiro, thanks a lot for providing your micro-benchmarks. So, did you use PrintAssemby/PrintOtpoAssembly to verify that the new nodes are matched? Regards, Volker On Fri, Jun 2, 2017 at 11:28 AM, Michihiro Horie > wrote: Volker, Thank you very much for the 2nd review. Attached includes micro benchmarks I used for the verification. (See attached file: reverseBytesBench.tar.gz) Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for Volker Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro a]Volker Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review From: Volker Simonis > To: "Doerr, Martin" > Cc: Michihiro Horie >, Gustavo Bueno Romero >, Hiroshi H Horii >, "hotspot-dev at openjdk.java.net" > Date: 2017/06/02 17:04 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store ________________________________ Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review Martin :) I'm just wondering if you had some test-cases to verify if the new nodes really match? Change looks good now. Regards, Volker On Thu, Jun 1, 2017 at 6:00 PM, Doerr, Martin > wrote: Hi Michihiro, thank you very much for providing the new webrev (with support for older Power processors, which was missing in webrev.02): http://cr.openjdk.java.net/~horii/8179527/webrev.03/ I have built and executed the VM on a Power6 machine. Thanks for supporting it. I would have spent only one flag for has_ldbrx/has_stdbrx, but I?m ok with it. The change looks good to me and I will sponsor it after 2nd review. Best regards, Martin From: Doerr, Martin Sent: Mittwoch, 31. Mai 2017 15:54 To: 'Michihiro Horie' >; Volker Simonis (volker.simonis at gmail.com) > Cc: Gustavo Bueno Romero >; Hiroshi H Horii >; hotspot-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thank you for the new webrev with all of my suggestions. Looks good to me. There?s only a trailing whitespace which I had to remove to satisfy ?hg jcheck? (otherwise push attempt would get rejected). We?ll run tests. Maybe we can get a 2nd review in the meantime? Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 31. Mai 2017 14:36 To: Doerr, Martin > Cc: Gustavo Bueno Romero >; Hiroshi H Horii >; hotspot-dev at openjdk.java.net; Simonis, Volker >; ppc-aix-port-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Martin, Thank you very much for your helpful comments and sponsoring this change. Would you review the latest change? http://cr.openjdk.java.net/~horii/8179527/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for "Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks bet]"Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of sugges From: "Doerr, Martin" > To: Michihiro Horie > Cc: "hotspot-dev at openjdk.java.net" >, "Simonis, Volker" >, Hiroshi H Horii >, Gustavo Bueno Romero > Date: 2017/05/30 01:26 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store ________________________________ Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of suggestions. 1. I still don?t like match rules which contain nodes which do something else (even though direct matching is prohibited by predicate). I think it would be better to remove ?match(?)?, ?predicate(false)? and ?ins_const(?)? and just describe the ?effect()?. At least, I?m not aware of why a match rule should be needed for rldicl and extsh. 2. I?d appreciate if you could remove ?predicate(UseCountLeadingZerosInstructionsPPC64)? from all byte_reverse_... rules. They don?t make any sense (not your fault). 3. The costs seem not to be set appropriately in the byte_reverse_... rules. E.g. instruction count * DEFAULT_COST would be better. 4. The load/store byte reversed instructions should use the 2 operand form (no explicit 0 for R0 to support assertions). Maybe we can find a 2nd reviewer if you provide a new webrev. I can sponsor the change. Thanks and best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 8. Mai 2017 06:58 To: Doerr, Martin >; Lindenmaier, Goetz > Cc: Gustavo Serra Scalet >; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >; Hiroshi H Horii >; Gustavo Bueno Romero > Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Dear Martin, Gustavo, Thank you very much for your helpful comments. Fixed code is http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Dear Goetz, Would you kindly review and sponsor this change? I heard you are a C2 compiler expert and Martin is out for a while. Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for "Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementi]"Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementing this change. From: "Doerr, Martin" > To: Gustavo Serra Scalet >, Michihiro Horie/Japan/IBM at IBMJP Cc: "ppc-aix-port-dev at openjdk.java.net" >, "hotspot-dev at openjdk.java.net" >, "Simonis, Volker" > Date: 2017/05/03 02:24 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store ________________________________ Hi Michihiro and Gustavo, thank you very much for implementing this change. @Gustavo: Thanks for taking a look. I think that the direct match rules are just there to satisfy match_rule_supported. They don't need to be fast, they are just a fall back solution. The goal is to exploit the byte reverse load and store instructions which should match in more performance critical cases. Now my review: assembler_ppc.hpp: Looks good except a minor formatting request: LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532 << 1), should be LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532u << 1), to be consistent. The comments // X-FORM should be aligned with the other ones. assembler_ppc.inline.hpp: Good. ppc.ad: I'm concerned about the additional match rules which are only used for the expand step. They could match directly leading to incorrect code. What they match is not what they do. I suggest to implement the code directly in the ins_encode. This would make the new code significantly shorter and less error prone. I think we don't need to optimize for Power6 anymore and newer processors shouldn't really suffer under a little less optimized instruction scheduling. Would you agree? Displacements may be too large for "li" so I suggest to use the "indirect" memory operand and let the compiler handle it. I know that it may increase latency because the compiler will need to insert an addition which could better be matched into the memory operand of the load which is harder to implement (it is possible to match an addition in an operand). Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Dienstag, 2. Mai 2017 17:05 To: Michihiro Horie > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Simonis, Volker >; Doerr, Martin > Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, I wonder if there is no vectorized approach for implementing your "bytes_reverse_long_Ex" instruct on ppc.ad. Or did you avoid doing it so intentionally? > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Michihiro Horie > Sent: ter?a-feira, 2 de maio de 2017 11:47 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > volker.simonis at sap.com; martin.doerr at sap.com > Subject: 8179527: Implement intrinsic code for reverseBytes with > load/store > > Dear all, > > Would you please review following change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179527 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > I added new intrinsic code for reverseBytes() in ppc.ad with > * match(Set dst (ReverseBytesI/L/US/S (LoadI src))); > * match(Set dst (StoreI dst (ReverseBytesI/L/US/S src))); > > > 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 Fri Jun 2 14:54:17 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Fri, 2 Jun 2017 22:54:17 +0800 Subject: 8179527: Implement intrinsic code for reverseBytes with load/store In-Reply-To: References: <7827421e2c6447f4ae406434f5bb3d25@sap.com> <552ec8649cfb48ccaf01ef7b238c0711@sap.com> Message-ID: Martin, Volker, Thank you very much for double-checking the change with micro benchmarks and pushing it. I should attach benchmarks with their results first time when I posted webrev, sorry. Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie , Volker Simonis Cc: Gustavo Bueno Romero , Hiroshi H Horii , "hotspot-dev at openjdk.java.net" , "ppc-aix-port-dev at openjdk.java.net" Date: 2017/06/02 22:39 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thanks for providing the micro benchmarks. I have run some of them on Power6 as additional test. All testing was good and we have 2 reviews, so I?ve pushed it. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Freitag, 2. Juni 2017 14:16 To: Volker Simonis Cc: Gustavo Bueno Romero ; Hiroshi H Horii ; hotspot-dev at openjdk.java.net; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Volker, I used OProfile's opannotate to verify the nodes are matched. Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for Volker Simonis ---2017/06/02 20:11:22---Hi Michihiro, thanks a lot for providing your micro-benchmarkVolker Simonis ---2017/06/02 20:11:22---Hi Michihiro, thanks a lot for providing your micro-benchmarks. From: Volker Simonis To: Michihiro Horie Cc: Gustavo Bueno Romero , Hiroshi H Horii < HORII at jp.ibm.com>, "hotspot-dev at openjdk.java.net" < hotspot-dev at openjdk.java.net>, "Doerr, Martin" , " ppc-aix-port-dev at openjdk.java.net" Date: 2017/06/02 20:11 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thanks a lot for providing your micro-benchmarks. So, did you use PrintAssemby/PrintOtpoAssembly to verify that the new nodes are matched? Regards, Volker On Fri, Jun 2, 2017 at 11:28 AM, Michihiro Horie wrote: Volker, Thank you very much for the 2nd review. Attached includes micro benchmarks I used for the verification. (See attached file: reverseBytesBench.tar.gz) Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for Volker Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro aVolker Simonis ---2017/06/02 17:04:16---Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review From: Volker Simonis To: "Doerr, Martin" Cc: Michihiro Horie , Gustavo Bueno Romero < gromero at br.ibm.com>, Hiroshi H Horii , " hotspot-dev at openjdk.java.net" Date: 2017/06/02 17:04 Subject: Re: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, Martin, thanks a lot for the change Michihiro and thanks for the thorough review Martin :) I'm just wondering if you had some test-cases to verify if the new nodes really match? Change looks good now. Regards, Volker On Thu, Jun 1, 2017 at 6:00 PM, Doerr, Martin wrote: Hi Michihiro, thank you very much for providing the new webrev (with support for older Power processors, which was missing in webrev.02): http://cr.openjdk.java.net/~horii/8179527/webrev.03/ I have built and executed the VM on a Power6 machine. Thanks for supporting it. I would have spent only one flag for has_ldbrx/has_stdbrx, but I?m ok with it. The change looks good to me and I will sponsor it after 2nd review. Best regards, Martin From: Doerr, Martin Sent: Mittwoch, 31. Mai 2017 15:54 To: 'Michihiro Horie' ; Volker Simonis (volker.simonis at gmail.com) Cc: Gustavo Bueno Romero ; Hiroshi H Horii ; hotspot-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thank you for the new webrev with all of my suggestions. Looks good to me. There?s only a trailing whitespace which I had to remove to satisfy ?hg jcheck? (otherwise push attempt would get rejected). We?ll run tests. Maybe we can get a 2nd review in the meantime? Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 31. Mai 2017 14:36 To: Doerr, Martin Cc: Gustavo Bueno Romero ; Hiroshi H Horii ; hotspot-dev at openjdk.java.net; Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Martin, Thank you very much for your helpful comments and sponsoring this change. Would you review the latest change? http://cr.openjdk.java.net/~horii/8179527/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks bet"Doerr, Martin" ---2017/05/30 01:26:01---Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of sugges From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-dev at openjdk.java.net" < hotspot-dev at openjdk.java.net>, "Simonis, Volker" < volker.simonis at sap.com>, Hiroshi H Horii < HORII at jp.ibm.com>, Gustavo Bueno Romero < gromero at br.ibm.com> Date: 2017/05/30 01:26 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, thanks for the improved webrev. This looks better, but I still have a couple of suggestions. 1. I still don?t like match rules which contain nodes which do something else (even though direct matching is prohibited by predicate). I think it would be better to remove ?match(?)?, ?predicate(false)? and ?ins_const(?)? and just describe the ?effect()?. At least, I?m not aware of why a match rule should be needed for rldicl and extsh. 2. I?d appreciate if you could remove ?predicate (UseCountLeadingZerosInstructionsPPC64)? from all byte_reverse_... rules. They don?t make any sense (not your fault). 3. The costs seem not to be set appropriately in the byte_reverse_... rules. E.g. instruction count * DEFAULT_COST would be better. 4. The load/store byte reversed instructions should use the 2 operand form (no explicit 0 for R0 to support assertions). Maybe we can find a 2nd reviewer if you provide a new webrev. I can sponsor the change. Thanks and best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Montag, 8. Mai 2017 06:58 To: Doerr, Martin ; Lindenmaier, Goetz Cc: Gustavo Serra Scalet ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker < volker.simonis at sap.com>; Hiroshi H Horii < HORII at jp.ibm.com>; Gustavo Bueno Romero < gromero at br.ibm.com> Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Dear Martin, Gustavo, Thank you very much for your helpful comments. Fixed code is http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Dear Goetz, Would you kindly review and sponsor this change? I heard you are a C2 compiler expert and Martin is out for a while. Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementi"Doerr, Martin" ---2017/05/03 02:24:18---Hi Michihiro and Gustavo, thank you very much for implementing this change. From: "Doerr, Martin" To: Gustavo Serra Scalet , Michihiro Horie/Japan/IBM at IBMJP Cc: "ppc-aix-port-dev at openjdk.java.net" < ppc-aix-port-dev at openjdk.java.net>, " hotspot-dev at openjdk.java.net" < hotspot-dev at openjdk.java.net>, "Simonis, Volker" < volker.simonis at sap.com> Date: 2017/05/03 02:24 Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro and Gustavo, thank you very much for implementing this change. @Gustavo: Thanks for taking a look. I think that the direct match rules are just there to satisfy match_rule_supported. They don't need to be fast, they are just a fall back solution. The goal is to exploit the byte reverse load and store instructions which should match in more performance critical cases. Now my review: assembler_ppc.hpp: Looks good except a minor formatting request: LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532 << 1), should be LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532u << 1), to be consistent. The comments // X-FORM should be aligned with the other ones. assembler_ppc.inline.hpp: Good. ppc.ad: I'm concerned about the additional match rules which are only used for the expand step. They could match directly leading to incorrect code. What they match is not what they do. I suggest to implement the code directly in the ins_encode. This would make the new code significantly shorter and less error prone. I think we don't need to optimize for Power6 anymore and newer processors shouldn't really suffer under a little less optimized instruction scheduling. Would you agree? Displacements may be too large for "li" so I suggest to use the "indirect" memory operand and let the compiler handle it. I know that it may increase latency because the compiler will need to insert an addition which could better be matched into the memory operand of the load which is harder to implement (it is possible to match an addition in an operand). Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [ mailto:gustavo.scalet at eldorado.org.br] Sent: Dienstag, 2. Mai 2017 17:05 To: Michihiro Horie Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Simonis, Volker < volker.simonis at sap.com>; Doerr, Martin < martin.doerr at sap.com> Subject: RE: 8179527: Implement intrinsic code for reverseBytes with load/store Hi Michihiro, I wonder if there is no vectorized approach for implementing your "bytes_reverse_long_Ex" instruct on ppc.ad. Or did you avoid doing it so intentionally? > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Michihiro Horie > Sent: ter?a-feira, 2 de maio de 2017 11:47 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > volker.simonis at sap.com; martin.doerr at sap.com > Subject: 8179527: Implement intrinsic code for reverseBytes with > load/store > > Dear all, > > Would you please review following change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179527 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > I added new intrinsic code for reverseBytes() in ppc.ad with > * match(Set dst (ReverseBytesI/L/US/S (LoadI src))); > * match(Set dst (StoreI dst (ReverseBytesI/L/US/S src))); > > > 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 gromero at linux.vnet.ibm.com Mon Jun 5 16:56:48 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 5 Jun 2017 13:56:48 -0300 Subject: PPC64/AIX nightly builds Message-ID: <59358D50.1010402@linux.vnet.ibm.com> Hi, Does anybody know any nightly build source from where one can download a build of OpenJDK 8 for PPC64/AIX? I'm aware of Volker's build results [1] but I could not find a way to download the builds itself, just the related build results. There is also a WIP on adoptopenjdk.net [2] but AIX setup is not ready yet... Thanks, Gustavo [1] http://cr.openjdk.java.net/~simonis/ppc-aix-port/ [2] https://adoptopenjdk.net/releases.html From gromero at linux.vnet.ibm.com Tue Jun 6 14:14:28 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 6 Jun 2017 11:14:28 -0300 Subject: PPC64/AIX nightly builds In-Reply-To: <59358D50.1010402@linux.vnet.ibm.com> References: <59358D50.1010402@linux.vnet.ibm.com> Message-ID: <5936B8C4.2050207@linux.vnet.ibm.com> Hi, Verifying around looks like that such a thing does not exist yet. Probably will exist in AdoptOpenJDK.net soon, hence I'll update that thread accordingly on news. Thanks! Regards, Gustavo On 05-06-2017 13:56, Gustavo Romero wrote: > Hi, > > Does anybody know any nightly build source from where one can download a build of > OpenJDK 8 for PPC64/AIX? > > I'm aware of Volker's build results [1] but I could not find a way to download the > builds itself, just the related build results. > > There is also a WIP on adoptopenjdk.net [2] but AIX setup is not ready yet... > > Thanks, > Gustavo > > [1] http://cr.openjdk.java.net/~simonis/ppc-aix-port/ > [2] https://adoptopenjdk.net/releases.html > From martin.doerr at sap.com Tue Jun 6 14:23:54 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Jun 2017 14:23:54 +0000 Subject: RFR(xs, jdk10, aix-only): 8171504: [aix] On AIX, -XXaltjvm= option is ignored In-Reply-To: References: <7b179216a3014caeaaf6dabc33b3687b@sap.com> Message-ID: <78667b800f114ddca5b061aa0095efc7@sap.com> Hi Thomas, as it's (almost) a copy from another OS implementation, I'm not requesting any changes. We only have to make sure we keep it in sync with the linux implementation in the future. Reviewed++ Best Regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Donnerstag, 27. April 2017 19:17 To: Langer, Christoph Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(xs, jdk10, aix-only): 8171504: [aix] On AIX, -XXaltjvm= option is ignored Thank you Christoph! ..Thomas On Thu, Apr 27, 2017 at 6:39 PM, Langer, Christoph wrote: > Hi Thomas, > > to me this AIX only change looks good - the only diff to the Linux > implementation is the realpath call. Reviewed. > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > > Sent: Mittwoch, 26. April 2017 16:03 > > To: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime- > > dev at openjdk.java.net > > Subject: RFR(xs, jdk10, aix-only): 8171504: [aix] On AIX, > -XXaltjvm= > > option is ignored > > > > Hi all, > > > > may I please have reviews for this small change. It adapts the -XXaltjvm > > handling to match all other platforms. > > > > (Note that this patch has not the intention of improving the code, I > almost > > verbatim copied the code from linux. Improvements were done in different > > changes, see e.g. JDK-8171508 ("os::jvm_path -XXaltjvm processing error > > after 8066474") and JDK-8173828 ("realpath is unsafe"). > > Issue: https://bugs.openjdk.java.net/browse/JDK-8171504 > > > > Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8171504-aix-xxaltjvm-path-is- > > ignored/webrev.00/webrev/ > > > > Thank you! > > > > Kind Regards, Thomas > From thomas.stuefe at gmail.com Tue Jun 6 15:11:23 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Jun 2017 17:11:23 +0200 Subject: RFR(xs, jdk10, aix-only): 8171504: [aix] On AIX, -XXaltjvm= option is ignored In-Reply-To: <78667b800f114ddca5b061aa0095efc7@sap.com> References: <7b179216a3014caeaaf6dabc33b3687b@sap.com> <78667b800f114ddca5b061aa0095efc7@sap.com> Message-ID: Thank you Martin! On Tue, Jun 6, 2017 at 4:23 PM, Doerr, Martin wrote: > Hi Thomas, > > as it's (almost) a copy from another OS implementation, I'm not requesting > any changes. We only have to make sure we keep it in sync with the linux > implementation in the future. > > Reviewed++ > > Best Regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Donnerstag, 27. April 2017 19:17 > To: Langer, Christoph > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk. > java.net > Subject: Re: RFR(xs, jdk10, aix-only): 8171504: [aix] On AIX, > -XXaltjvm= option is ignored > > Thank you Christoph! > ..Thomas > > On Thu, Apr 27, 2017 at 6:39 PM, Langer, Christoph < > christoph.langer at sap.com > > wrote: > > > Hi Thomas, > > > > to me this AIX only change looks good - the only diff to the Linux > > implementation is the realpath call. Reviewed. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > > > Sent: Mittwoch, 26. April 2017 16:03 > > > To: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime- > > > dev at openjdk.java.net > > > Subject: RFR(xs, jdk10, aix-only): 8171504: [aix] On AIX, > > -XXaltjvm= > > > option is ignored > > > > > > Hi all, > > > > > > may I please have reviews for this small change. It adapts the > -XXaltjvm > > > handling to match all other platforms. > > > > > > (Note that this patch has not the intention of improving the code, I > > almost > > > verbatim copied the code from linux. Improvements were done in > different > > > changes, see e.g. JDK-8171508 ("os::jvm_path -XXaltjvm processing error > > > after 8066474") and JDK-8173828 ("realpath is unsafe"). > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8171504 > > > > > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8171504-aix- > xxaltjvm-path-is- > > > ignored/webrev.00/webrev/ > > > > > > Thank you! > > > > > > Kind Regards, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From AROBERTS at uk.ibm.com Mon Jun 12 14:57:53 2017 From: AROBERTS at uk.ibm.com (Adam Roberts) Date: Mon, 12 Jun 2017 15:57:53 +0100 Subject: Building jdk-8u on AIX 7.2 problems: sizeof Message-ID: Hi, I'm looking to get OpenJDK 8 built on Power big-endian using AIX 7.2. I have xlc 12.1 and a small configuration script that currently does the following to overcome initial hurdles when configuring. I'm working off the latest 8 head. bash-4.3# cat AdamConfig.sh export CC="xlc" export CXX="xlc" export JDK_BOOT_DIR=/usr/java7_64 export PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java7_64/jre/bin:/usr/java7_64/bin:/usr/local/bin:/usr/vac/bin I source this first and then go on to ./configure. bash-4.3# cat openjdk/config.log | grep "The tested" configure:29034: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64). configure:29100: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64) As above, when configuring I can't get past the checking size of int* step. Two observations 1) I can compile and run a regular C application with xlc using 64 bit pointers with either OBJECT_MODE=64 set as an environment variable or -q64 set as a build option 2) If I look in config.log I see this - notice the lack of -q64 being used configure:28993: checking size of int * configure:28998: /usr/vac/bin/xlc -o conftest -m64 -m64 conftest.cpp >&5 /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld ld: 0706-012 The -6 flag is not recognized. ld: 0706-012 The -4 flag is not recognized. ld: 0706-012 The -6 flag is not recognized. configure:28965: /usr/vac/bin/xlc -E conftest.cpp configure:28965: $? = 0 configure:28965: result: yes configure:28965: checking for stdio.h configure:28965: result: yes configure:28993: checking size of int * configure:28998: /usr/vac/bin/xlc -o conftest -m64 -m64 conftest.cpp >&5 /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld ld: 0706-012 The -6 flag is not recognized. Is there some option I'm not aware of that'll enable me to build trivially with xlc? Perhaps some extra work to be done to enable this? The sizeof check is defined as AC_CHECK_SIZEOF([int *], [1111]) in openjdk/common/autoconf/platform.m4 Full configure log available on request, it does mention COMPILER_NAME=gcc. But surely I can't use gcc because I see we do a -qversion call with xlc to determine the compiler version (and that is an xlc specific option AFAIK). Feels like I'm missing something here! Cheers in advance 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 Mon Jun 12 16:23:38 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 12 Jun 2017 18:23:38 +0200 Subject: Building jdk-8u on AIX 7.2 problems: sizeof In-Reply-To: References: Message-ID: Hi Adam, I think (not sure) that defining CC=xlc may the problem. Try to remove it, and CXX too, setting it should not be necessary if xlc is in the path. See toolchain.m4: 412 # Option used to tell the compiler whether to create 32- or 64-bit executables 413 # Notice that CC contains the full compiler path at this point. 414 case $CC in 415 *xlc_r) COMPILER_TARGET_BITS_FLAG="-q";; 416 *) COMPILER_TARGET_BITS_FLAG="-m";; 417 esac "xlc" != "xlc_r", so we pick up COMPILER_TARGET_BITS_FLAG=-m, so we call xlc with -m64, which it does not understand. The resulting binary has whatever is the default, with OBJECT_MODE unset this is probably 32 bit. Which gives the wrong sizeof(). This is just a guess, I was not able to try it for myself. Kind Regards, Thomas On Mon, Jun 12, 2017 at 4:57 PM, Adam Roberts wrote: > Hi, I'm looking to get OpenJDK 8 built on Power big-endian using AIX 7.2. > > I have xlc 12.1 and a small configuration script that currently does the > following to overcome initial hurdles when configuring. I'm working off the > latest 8 head. > > bash-4.3# cat AdamConfig.sh > export CC="xlc" > export CXX="xlc" > export JDK_BOOT_DIR=/usr/java7_64 > export PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/ > usr/java7_64/jre/bin:/usr/java7_64/bin:/usr/local/bin:/usr/vac/bin > > I source this first and then go on to ./configure. > > bash-4.3# cat openjdk/config.log | grep "The tested" > configure:29034: The tested number of bits in the target (0) differs from > the number of bits expected to be found in the target (64). > configure:29100: error: The tested number of bits in the target (0) > differs from the number of bits expected to be found in the target (64) > > As above, when configuring I can't get past the checking size of int* step. > > Two observations > 1) I can compile and run a regular C application with xlc using 64 bit > pointers with either OBJECT_MODE=64 set as an environment variable or -q64 > set as a build option > 2) If I look in config.log I see this - notice the lack of -q64 being used > > configure:28993: checking size of int * > configure:28998: /usr/vac/bin/xlc -o conftest -m64 -m64 conftest.cpp > >&5 > /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - > passed to ld > /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - > passed to ld > ld: 0706-012 The -6 flag is not recognized. > ld: 0706-012 The -4 flag is not recognized. > ld: 0706-012 The -6 flag is not recognized. > configure:28965: /usr/vac/bin/xlc -E conftest.cpp > configure:28965: $? = 0 > configure:28965: result: yes > configure:28965: checking for stdio.h > configure:28965: result: yes > configure:28993: checking size of int * > configure:28998: /usr/vac/bin/xlc -o conftest -m64 -m64 conftest.cpp > >&5 > /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - > passed to ld > /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - > passed to ld > ld: 0706-012 The -6 flag is not recognized. > > Is there some option I'm not aware of that'll enable me to build trivially > with xlc? Perhaps some extra work to be done to enable this? > > The sizeof check is defined as > > AC_CHECK_SIZEOF([int *], [1111]) > > in openjdk/common/autoconf/platform.m4 > > Full configure log available on request, it does mention > COMPILER_NAME=gcc. But surely I can't use gcc because I see we do a > -qversion call with xlc to determine the compiler version (and that is an > xlc specific option AFAIK). > > Feels like I'm missing something here! > > Cheers in advance > > > 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 AROBERTS at uk.ibm.com Tue Jun 13 12:39:24 2017 From: AROBERTS at uk.ibm.com (Adam Roberts) Date: Tue, 13 Jun 2017 13:39:24 +0100 Subject: Building jdk-8u on AIX 7.2 problems: sizeof In-Reply-To: References: Message-ID: Thanks Thomas, getting xlc 13.1 installed (including the C++ compiler instead of just the C compiler) resolves my problem: I set my path to include both the xlc/bin and xlC/bin (notice the uppercase C for C++) directories and the configure step passes. Next problem is to do with missing pthread symbols now when building the VM, but I'll have a good go at fixing this first before potentially asking for help here again Cheers, From: Thomas St?fe To: Adam Roberts Cc: "ppc-aix-port-dev at openjdk.java.net" Date: 12/06/2017 17:23 Subject: Re: Building jdk-8u on AIX 7.2 problems: sizeof Hi Adam, I think (not sure) that defining CC=xlc may the problem. Try to remove it, and CXX too, setting it should not be necessary if xlc is in the path. See toolchain.m4: 412 # Option used to tell the compiler whether to create 32- or 64-bit executables 413 # Notice that CC contains the full compiler path at this point. 414 case $CC in 415 *xlc_r) COMPILER_TARGET_BITS_FLAG="-q";; 416 *) COMPILER_TARGET_BITS_FLAG="-m";; 417 esac "xlc" != "xlc_r", so we pick up COMPILER_TARGET_BITS_FLAG=-m, so we call xlc with -m64, which it does not understand. The resulting binary has whatever is the default, with OBJECT_MODE unset this is probably 32 bit. Which gives the wrong sizeof(). This is just a guess, I was not able to try it for myself. Kind Regards, Thomas On Mon, Jun 12, 2017 at 4:57 PM, Adam Roberts wrote: Hi, I'm looking to get OpenJDK 8 built on Power big-endian using AIX 7.2. I have xlc 12.1 and a small configuration script that currently does the following to overcome initial hurdles when configuring. I'm working off the latest 8 head. bash-4.3# cat AdamConfig.sh export CC="xlc" export CXX="xlc" export JDK_BOOT_DIR=/usr/java7_64 export PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java7_64/jre/bin:/usr/java7_64/bin:/usr/local/bin:/usr/vac/bin I source this first and then go on to ./configure. bash-4.3# cat openjdk/config.log | grep "The tested" configure:29034: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64). configure:29100: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64) As above, when configuring I can't get past the checking size of int* step. Two observations 1) I can compile and run a regular C application with xlc using 64 bit pointers with either OBJECT_MODE=64 set as an environment variable or -q64 set as a build option 2) If I look in config.log I see this - notice the lack of -q64 being used configure:28993: checking size of int * configure:28998: /usr/vac/bin/xlc -o conftest -m64 -m64 conftest.cpp >&5 /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld ld: 0706-012 The -6 flag is not recognized. ld: 0706-012 The -4 flag is not recognized. ld: 0706-012 The -6 flag is not recognized. configure:28965: /usr/vac/bin/xlc -E conftest.cpp configure:28965: $? = 0 configure:28965: result: yes configure:28965: checking for stdio.h configure:28965: result: yes configure:28993: checking size of int * configure:28998: /usr/vac/bin/xlc -o conftest -m64 -m64 conftest.cpp >&5 /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld /usr/vac/bin/xlc: 1501-216 (W) command option -64 is not recognized - passed to ld ld: 0706-012 The -6 flag is not recognized. Is there some option I'm not aware of that'll enable me to build trivially with xlc? Perhaps some extra work to be done to enable this? The sizeof check is defined as AC_CHECK_SIZEOF([int *], [1111]) in openjdk/common/autoconf/platform.m4 Full configure log available on request, it does mention COMPILER_NAME=gcc. But surely I can't use gcc because I see we do a -qversion call with xlc to determine the compiler version (and that is an xlc specific option AFAIK). Feels like I'm missing something here! Cheers in advance 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 mbrandy at linux.vnet.ibm.com Mon Jun 19 16:27:36 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Mon, 19 Jun 2017 11:27:36 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 Message-ID: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> 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. Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt From mbrandy at linux.vnet.ibm.com Mon Jun 19 16:30:28 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Mon, 19 Jun 2017 11:30:28 -0500 Subject: RFR(S) JDK-8181810 PPC64: Leverage extrdi for bitfield extract Message-ID: <2f852cff-938e-b383-cf2b-66f97fe652ff@linux.vnet.ibm.com> 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. Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt From mbrandy at linux.vnet.ibm.com Mon Jun 19 16:35:20 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Mon, 19 Jun 2017 11:35:20 -0500 Subject: RFR(S) JDK-8181810 PPC64: Leverage extrdi for bitfield extract In-Reply-To: <2f852cff-938e-b383-cf2b-66f97fe652ff@linux.vnet.ibm.com> References: <2f852cff-938e-b383-cf2b-66f97fe652ff@linux.vnet.ibm.com> Message-ID: <21843b61-4ca1-a85e-8627-2270af1079f6@linux.vnet.ibm.com> Apologies for the bad cut-and-paste job.. the body of this review request should read as follows: This is a PPC-specific hotspot optimization that leverages the extrdi instruction for bitfield extract operations (shift-right and mask-with-and). It yields a ~25% improvement measured via a microbenchmark. Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8181810 Webrev: http://cr.openjdk.java.net/~gromero/8181810/v1/ Thanks, Matt On 6/19/17 11:30 AM, Matthew Brandyberry wrote: > 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. > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181809 > Webrev: http://cr.openjdk.java.net/~gromero/8181809/v1/ > > Thanks, > Matt > From martin.doerr at sap.com Tue Jun 20 13:33:59 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Jun 2017 13:33:59 +0000 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> Message-ID: <2a4fcb315f4d44199e8cc66935886f41@sap.com> Hi Matt, thanks for providing this webrev. I had already thought about using these instructions for this purpose and your change matches pretty much what I'd do. Here a couple of comments: ppc.ad: This was a lot of work. Thanks for doing it. effect(DEF dst, USE src); is redundant if a match rule match(Set dst (MoveL2D src)); exists. vm_version: This part is in conflict with Michihiro's change which is already pushed in jdk10, but it's trivial to resolve. I'm ok with using has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble with assuming that a certain Power processor supports all new instructions if it supports certain ones. We also use the hotspot code on as400 where certain instruction subsets were disabled while other Power 8 instructions were usable. Maybe you can double-check if there may exist configurations in which has_vpmsumb() doesn't match has_mtfprd(). C1: It should also be possible to use the instructions in C1 compiler. Maybe you would like to take a look at it as well and see if it can be done with feasible effort. Here are some hints: The basic decisions are made in LIRGenerator::do_Convert. You could skip the force_to_spill or must_start_in_memory steps. The final assembly code gets emitted in LIR_Assembler::emit_opConvert where you could replace the store instructions. For testing, you can use -XX:TieredStopAtLevel=1, for example. Thanks and best regards, Martin -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Matthew Brandyberry Sent: Montag, 19. Juni 2017 18:28 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 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. Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt From mbrandy at linux.vnet.ibm.com Tue Jun 20 13:38:57 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Tue, 20 Jun 2017 08:38:57 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <2a4fcb315f4d44199e8cc66935886f41@sap.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> Message-ID: <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> Hi Martin, Thanks for the review. I'll take a look at these areas and report back -- especially the integration into C1. On 6/20/17 8:33 AM, Doerr, Martin wrote: > Hi Matt, > > thanks for providing this webrev. I had already thought about using these instructions for this purpose and your change matches pretty much what I'd do. > > Here a couple of comments: > ppc.ad: > This was a lot of work. Thanks for doing it. > effect(DEF dst, USE src); is redundant if a match rule match(Set dst (MoveL2D src)); exists. > > vm_version: > This part is in conflict with Michihiro's change which is already pushed in jdk10, but it's trivial to resolve. I'm ok with using has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble with assuming that a certain Power processor supports all new instructions if it supports certain ones. We also use the hotspot code on as400 where certain instruction subsets were disabled while other Power 8 instructions were usable. Maybe you can double-check if there may exist configurations in which has_vpmsumb() doesn't match has_mtfprd(). > > C1: > It should also be possible to use the instructions in C1 compiler. Maybe you would like to take a look at it as well and see if it can be done with feasible effort. > Here are some hints: > The basic decisions are made in LIRGenerator::do_Convert. You could skip the force_to_spill or must_start_in_memory steps. > The final assembly code gets emitted in LIR_Assembler::emit_opConvert where you could replace the store instructions. > For testing, you can use -XX:TieredStopAtLevel=1, for example. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Matthew Brandyberry > Sent: Montag, 19. Juni 2017 18:28 > To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 > > 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. Please review: Bug: > https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: > http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt > > From mbrandy at linux.vnet.ibm.com Tue Jun 20 13:46:25 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Tue, 20 Jun 2017 08:46:25 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <20170620134406.GD14487@physik.fu-berlin.de> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <20170620134406.GD14487@physik.fu-berlin.de> Message-ID: Hi Adrian, These instructions were introduced with POWER8 and are not available in earlier ISAs. On 6/20/17 8:44 AM, John Paul Adrian Glaubitz wrote: > Hi Matthew! > > On Mon, Jun 19, 2017 at 11:27:36AM -0500, Matthew Brandyberry wrote: >> 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). > Do these instructions also exist on POWER5 or is this POWER8+ only? > > Adrian > From mbrandy at linux.vnet.ibm.com Tue Jun 20 14:03:07 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Tue, 20 Jun 2017 09:03:07 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <20170620135807.GE14487@physik.fu-berlin.de> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <20170620134406.GD14487@physik.fu-berlin.de> <20170620135807.GE14487@physik.fu-berlin.de> Message-ID: <1b51ebad-0b4c-9f95-1d34-5119ca121131@linux.vnet.ibm.com> I think they are all guarded properly -- some at a higher level via predicate directives. Which instance(s) in particular look unguarded? On 6/20/17 8:58 AM, John Paul Adrian Glaubitz wrote: > On Tue, Jun 20, 2017 at 08:46:25AM -0500, Matthew Brandyberry wrote: >> These instructions were introduced with POWER8 and are not available in >> earlier ISAs. > Isn't your patch then missing some guarding such that these > instructions aren't used when building on ppc64be with POWER5? > > We're still building openjdk-9 in Debian on ppc64 with POWER5 besides > the ppc64el build with POWER8. > > Thanks, > Adrian > From glaubitz at physik.fu-berlin.de Tue Jun 20 13:44:07 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 20 Jun 2017 15:44:07 +0200 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> Message-ID: <20170620134406.GD14487@physik.fu-berlin.de> Hi Matthew! On Mon, Jun 19, 2017 at 11:27:36AM -0500, Matthew Brandyberry wrote: > 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). Do these instructions also exist on POWER5 or is this POWER8+ only? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Jun 20 13:58:07 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 20 Jun 2017 15:58:07 +0200 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <20170620134406.GD14487@physik.fu-berlin.de> Message-ID: <20170620135807.GE14487@physik.fu-berlin.de> On Tue, Jun 20, 2017 at 08:46:25AM -0500, Matthew Brandyberry wrote: > These instructions were introduced with POWER8 and are not available in > earlier ISAs. Isn't your patch then missing some guarding such that these instructions aren't used when building on ppc64be with POWER5? We're still building openjdk-9 in Debian on ppc64 with POWER5 besides the ppc64el build with POWER8. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Jun 20 14:06:09 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 20 Jun 2017 16:06:09 +0200 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <1b51ebad-0b4c-9f95-1d34-5119ca121131@linux.vnet.ibm.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <20170620134406.GD14487@physik.fu-berlin.de> <20170620135807.GE14487@physik.fu-berlin.de> <1b51ebad-0b4c-9f95-1d34-5119ca121131@linux.vnet.ibm.com> Message-ID: <20170620140609.GF14487@physik.fu-berlin.de> On Tue, Jun 20, 2017 at 09:03:07AM -0500, Matthew Brandyberry wrote: > I think they are all guarded properly -- some at a higher level via > predicate directives. Which instance(s) in particular look unguarded? Ah, I was just looking for #ifdefs when in fact there is "if (VM_Version::has_mtfprd())" which is apparently what I should have been looking for. Sorry for my ignorance and thanks for the quick replies! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From Gordon_CY_Wu at amat.com Thu Jun 22 01:22:29 2017 From: Gordon_CY_Wu at amat.com (Gordon_CY_Wu at amat.com) Date: Thu, 22 Jun 2017 01:22:29 +0000 Subject: Failed to download the bootstrap JDK Message-ID: Hi, All I am trying to download the bootstrap JDK ( openjdk1.7.0-ppc-aix-port-aix-ppc64-b03.tar.bz2 openjdk_8u40_b13-aix-ppc64.tar.bz2. ) following the link from http://cr.openjdk.java.net/~simonis/ppc-aix-port, but did not succeed. Are those files still existed? Where can I download the files, so I can build the openjdk for AIX on my AIX system? Thanks and Regards Gordon CY Wu Support Engineer|TPS | Automation Products AGS | Applied Materials Office 801.736.3347| Mobile 801.380.5910 | Support Hot Line 801.488.2277 The content of this message is Applied Materials Confidential. If you are not the intended recipient and have received this message in error, any use or distribution is prohibited. Please notify me immediately by reply e-mail and delete this message from your computer system. Thank you. P Save a tree. Please don't print this e-mail unless needed. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Jun 22 16:09:38 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 22 Jun 2017 18:09:38 +0200 Subject: Failed to download the bootstrap JDK In-Reply-To: References: Message-ID: Hi Gordon, the AIX bootstrap jdk you mention is pretty old and unfortunately not availabl any more due to a crash on the server which used to provide it. The Adopt OpenJDK group is currently running an effort to create a continuous OpenJDK build on all OpenJDK platforms. They have a slack group [2] and I've just send you an invitation for it. In the #aix channel of that group I've recently posted an openjdk7 build which you can use as boot jdk on AIX. Regards, Volker [1] https://wiki.openjdk.java.net/display/Adoption/Main [2] https://adoptopenjdk.slack.com On Thu, Jun 22, 2017 at 3:22 AM, wrote: > Hi, All > > > > I am trying to download the bootstrap JDK ( > openjdk1.7.0-ppc-aix-port-aix-ppc64-b03.tar.bz2 > openjdk_8u40_b13-aix-ppc64.tar.bz2. ) following the link from > http://cr.openjdk.java.net/~simonis/ppc-aix-port, but did not succeed. > > Are those files still existed? Where can I download the files, so I can > build the openjdk for AIX on my AIX system? > > > > Thanks and Regards > > Gordon CY Wu > > Support Engineer|TPS | Automation Products AGS | Applied Materials > Office 801.736.3347| Mobile 801.380.5910 | Support Hot Line 801.488.2277 > > > > The content of this message is Applied Materials Confidential. If you are > not the intended recipient and have received this message in error, any use > or distribution is prohibited. Please notify me immediately by reply e-mail > and delete this message from your computer system. Thank you. > > P Save a tree. Please don't print this e-mail unless needed. > > > > > ________________________________ > From mbrandy at linux.vnet.ibm.com Fri Jun 23 02:53:30 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Thu, 22 Jun 2017 21:53:30 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> Message-ID: <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> Updated webrev: http://cr.openjdk.java.net/~gromero/8181809/v2/ See below for responses inline. On 6/20/17 8:38 AM, Matthew Brandyberry wrote: > Hi Martin, > > Thanks for the review. I'll take a look at these areas and report > back -- especially the integration into C1. > > On 6/20/17 8:33 AM, Doerr, Martin wrote: >> Hi Matt, >> >> thanks for providing this webrev. I had already thought about using >> these instructions for this purpose and your change matches pretty >> much what I'd do. >> >> Here a couple of comments: >> ppc.ad: >> This was a lot of work. Thanks for doing it. >> effect(DEF dst, USE src); is redundant if a match rule match(Set dst >> (MoveL2D src)); exists. Fixed. >> >> vm_version: >> This part is in conflict with Michihiro's change which is already >> pushed in jdk10, but it's trivial to resolve. I'm ok with using >> has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble >> with assuming that a certain Power processor supports all new >> instructions if it supports certain ones. We also use the hotspot >> code on as400 where certain instruction subsets were disabled while >> other Power 8 instructions were usable. Maybe you can double-check if >> there may exist configurations in which has_vpmsumb() doesn't match >> has_mtfprd(). I could not find evidence of any config that includes vpmsumb but not mtfprd. >> >> C1: >> It should also be possible to use the instructions in C1 compiler. >> Maybe you would like to take a look at it as well and see if it can >> be done with feasible effort. >> Here are some hints: >> The basic decisions are made in LIRGenerator::do_Convert. You could >> skip the force_to_spill or must_start_in_memory steps. >> The final assembly code gets emitted in LIR_Assembler::emit_opConvert >> where you could replace the store instructions. >> For testing, you can use -XX:TieredStopAtLevel=1, for example. Done. Please take a look. >> >> Thanks and best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Matthew Brandyberry >> Sent: Montag, 19. Juni 2017 18:28 >> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >> >> 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. Please review: Bug: >> https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: >> http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt >> >> > From volker.simonis at gmail.com Fri Jun 23 07:14:09 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 23 Jun 2017 09:14:09 +0200 Subject: C++11/C++14 support in XLC ? Message-ID: Hi everybody, Kim recently approached me with some questions regarding the amount and quality of C++11/C++14 support in XLC (see his mail below). As he found out, it seems that there's unfortunately not much of even C++11 support in recent XLC compilers [1,2]. I think, one of the features most badly needed is the support for atomics operations library [3] which was introduced with C++11. A recent hotspot mail thread [4,5] may give an impression why the atomics library is need (but obviously only makes sense if it is high-quality, bullet-proof on all supported platforms) I would be great if somebody from the IBM folks on this list could provide some more detailed information on the current state of the C++11/C++14/C++XX support in XLC and the future plans if possible. Thank you and best regards, Volker ---------- Forwarded message ---------- From: Kim Barrett Date: Wed, Jun 21, 2017 at 6:23 AM Subject: c++11 ? To: Volker Simonis Hi Volker, There's been a lot of internal discussion here at Oracle about possibly updating compilers and starting to use C++11 or even C++14 features, for JDK10 or beyond. Until recently I thought C++11 was practical, just a matter of doing the work. This was based in part on information I'd seen about XLC++ supporting C++11. However, I recently found documentation [1] [2] indicating that's only true for the Linux port, and that even the latest version of the AIX port is seriously laggard, only providing a few specific C++11 features. If that's accurate, that's very disappointing. I was wondering if you or your group might have any additional information or thoughts? [1] https://www-03.ibm.com/software/products/en/xlcpp-aix [2] https://www-01.ibm.com/support/docview.wss?uid=swg27047114 [3] http://en.cppreference.com/w/cpp/atomic [4] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-May/thread.html#224 [5] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/thread.html#268 From t.p.ellison at gmail.com Fri Jun 23 08:27:11 2017 From: t.p.ellison at gmail.com (Tim Ellison) Date: Fri, 23 Jun 2017 09:27:11 +0100 Subject: C++11/C++14 support in XLC ? In-Reply-To: References: Message-ID: <9ab1bb7e-3fa1-187b-0199-fc1bbbf4a31d@gmail.com> I don't know the answer myself, but I will reach out to the compiler folks inside IBM and get response. Regards, Tim On 23/06/17 08:14, Volker Simonis wrote: > Hi everybody, > > Kim recently approached me with some questions regarding the amount > and quality of C++11/C++14 support in XLC (see his mail below). As he > found out, it seems that there's unfortunately not much of even C++11 > support in recent XLC compilers [1,2]. > > I think, one of the features most badly needed is the support for > atomics operations library [3] which was introduced with C++11. A > recent hotspot mail thread [4,5] may give an impression why the > atomics library is need (but obviously only makes sense if it is > high-quality, bullet-proof on all supported platforms) > > I would be great if somebody from the IBM folks on this list could > provide some more detailed information on the current state of the > C++11/C++14/C++XX support in XLC and the future plans if possible. > > Thank you and best regards, > Volker > > > ---------- Forwarded message ---------- > From: Kim Barrett > Date: Wed, Jun 21, 2017 at 6:23 AM > Subject: c++11 ? > To: Volker Simonis > > Hi Volker, > > There's been a lot of internal discussion here at Oracle about > possibly updating compilers and starting to use C++11 or even C++14 > features, for JDK10 or beyond. Until recently I thought C++11 was > practical, just a matter of doing the work. This was based in part on > information I'd seen about XLC++ supporting C++11. However, I > recently found documentation [1] [2] indicating that's only true for > the Linux port, and that even the latest version of the AIX port is > seriously laggard, only providing a few specific C++11 features. If > that's accurate, that's very disappointing. I was wondering if you or > your group might have any additional information or thoughts? > > [1] https://www-03.ibm.com/software/products/en/xlcpp-aix > [2] https://www-01.ibm.com/support/docview.wss?uid=swg27047114 > [3] http://en.cppreference.com/w/cpp/atomic > [4] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-May/thread.html#224 > [5] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/thread.html#268 > From martin.doerr at sap.com Fri Jun 23 09:30:08 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 23 Jun 2017 09:30:08 +0000 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> Message-ID: Excellent. Thanks for the update. The C1 part looks good, too. Also, thanks for checking "I could not find evidence of any config that includes vpmsumb but not mtfprd." There are only a few formally required things: - The new C1 code contains Tab characters. It's not possible to push it without fixing this. - Copyright messages should be updated. - Minor resolution to get vm_version_ppc applied to recent jdk10/hs. If no other changes get requested, I can handle these issues this time before pushing. But we need another review, first. Thanks and best regards, Martin -----Original Message----- From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] Sent: Freitag, 23. Juni 2017 04:54 To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 Updated webrev: http://cr.openjdk.java.net/~gromero/8181809/v2/ See below for responses inline. On 6/20/17 8:38 AM, Matthew Brandyberry wrote: > Hi Martin, > > Thanks for the review. I'll take a look at these areas and report > back -- especially the integration into C1. > > On 6/20/17 8:33 AM, Doerr, Martin wrote: >> Hi Matt, >> >> thanks for providing this webrev. I had already thought about using >> these instructions for this purpose and your change matches pretty >> much what I'd do. >> >> Here a couple of comments: >> ppc.ad: >> This was a lot of work. Thanks for doing it. >> effect(DEF dst, USE src); is redundant if a match rule match(Set dst >> (MoveL2D src)); exists. Fixed. >> >> vm_version: >> This part is in conflict with Michihiro's change which is already >> pushed in jdk10, but it's trivial to resolve. I'm ok with using >> has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble >> with assuming that a certain Power processor supports all new >> instructions if it supports certain ones. We also use the hotspot >> code on as400 where certain instruction subsets were disabled while >> other Power 8 instructions were usable. Maybe you can double-check if >> there may exist configurations in which has_vpmsumb() doesn't match >> has_mtfprd(). I could not find evidence of any config that includes vpmsumb but not mtfprd. >> >> C1: >> It should also be possible to use the instructions in C1 compiler. >> Maybe you would like to take a look at it as well and see if it can >> be done with feasible effort. >> Here are some hints: >> The basic decisions are made in LIRGenerator::do_Convert. You could >> skip the force_to_spill or must_start_in_memory steps. >> The final assembly code gets emitted in LIR_Assembler::emit_opConvert >> where you could replace the store instructions. >> For testing, you can use -XX:TieredStopAtLevel=1, for example. Done. Please take a look. >> >> Thanks and best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Matthew Brandyberry >> Sent: Montag, 19. Juni 2017 18:28 >> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >> >> 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. Please review: Bug: >> https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: >> http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt >> >> > From mbrandy at linux.vnet.ibm.com Fri Jun 23 16:38:35 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Fri, 23 Jun 2017 11:38:35 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> Message-ID: <20c43bf4-a66b-2cc8-e62f-d58eb66df278@linux.vnet.ibm.com> Thanks Martin. Are there tools to help detect formatting errors like the tab characters? I'll keep an eye on this to see if I need to do anything else. -Matt On 6/23/17 4:30 AM, Doerr, Martin wrote: > Excellent. Thanks for the update. The C1 part looks good, too. > > Also, thanks for checking "I could not find evidence of any config that includes vpmsumb but not > mtfprd." > > There are only a few formally required things: > - The new C1 code contains Tab characters. It's not possible to push it without fixing this. > - Copyright messages should be updated. > - Minor resolution to get vm_version_ppc applied to recent jdk10/hs. > > If no other changes get requested, I can handle these issues this time before pushing. > But we need another review, first. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] > Sent: Freitag, 23. Juni 2017 04:54 > To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 > > Updated webrev: http://cr.openjdk.java.net/~gromero/8181809/v2/ > > See below for responses inline. > > On 6/20/17 8:38 AM, Matthew Brandyberry wrote: >> Hi Martin, >> >> Thanks for the review. I'll take a look at these areas and report >> back -- especially the integration into C1. >> >> On 6/20/17 8:33 AM, Doerr, Martin wrote: >>> Hi Matt, >>> >>> thanks for providing this webrev. I had already thought about using >>> these instructions for this purpose and your change matches pretty >>> much what I'd do. >>> >>> Here a couple of comments: >>> ppc.ad: >>> This was a lot of work. Thanks for doing it. >>> effect(DEF dst, USE src); is redundant if a match rule match(Set dst >>> (MoveL2D src)); exists. > Fixed. >>> vm_version: >>> This part is in conflict with Michihiro's change which is already >>> pushed in jdk10, but it's trivial to resolve. I'm ok with using >>> has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble >>> with assuming that a certain Power processor supports all new >>> instructions if it supports certain ones. We also use the hotspot >>> code on as400 where certain instruction subsets were disabled while >>> other Power 8 instructions were usable. Maybe you can double-check if >>> there may exist configurations in which has_vpmsumb() doesn't match >>> has_mtfprd(). > I could not find evidence of any config that includes vpmsumb but not > mtfprd. >>> C1: >>> It should also be possible to use the instructions in C1 compiler. >>> Maybe you would like to take a look at it as well and see if it can >>> be done with feasible effort. >>> Here are some hints: >>> The basic decisions are made in LIRGenerator::do_Convert. You could >>> skip the force_to_spill or must_start_in_memory steps. >>> The final assembly code gets emitted in LIR_Assembler::emit_opConvert >>> where you could replace the store instructions. >>> For testing, you can use -XX:TieredStopAtLevel=1, for example. > Done. Please take a look. >>> Thanks and best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Matthew Brandyberry >>> Sent: Montag, 19. Juni 2017 18:28 >>> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >>> >>> 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. Please review: Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: >>> http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt >>> >>> From Gordon_CY_Wu at amat.com Sat Jun 24 05:13:21 2017 From: Gordon_CY_Wu at amat.com (Gordon_CY_Wu at amat.com) Date: Sat, 24 Jun 2017 05:13:21 +0000 Subject: Failed to download the bootstrap JDK In-Reply-To: References: Message-ID: Hi, Volker, Thanks for the information and thanks for inviting me to the group. Very helpful. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Thursday, June 22, 2017 10:10 AM To: Gordon CY Wu Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: Failed to download the bootstrap JDK Hi Gordon, the AIX bootstrap jdk you mention is pretty old and unfortunately not availabl any more due to a crash on the server which used to provide it. The Adopt OpenJDK group is currently running an effort to create a continuous OpenJDK build on all OpenJDK platforms. They have a slack group [2] and I've just send you an invitation for it. In the #aix channel of that group I've recently posted an openjdk7 build which you can use as boot jdk on AIX. Regards, Volker [1] https://wiki.openjdk.java.net/display/Adoption/Main [2] https://adoptopenjdk.slack.com On Thu, Jun 22, 2017 at 3:22 AM, wrote: > Hi, All > > > > I am trying to download the bootstrap JDK ( > openjdk1.7.0-ppc-aix-port-aix-ppc64-b03.tar.bz2 > openjdk_8u40_b13-aix-ppc64.tar.bz2. ) following the link from > http://cr.openjdk.java.net/~simonis/ppc-aix-port, but did not succeed. > > Are those files still existed? Where can I download the files, so I > can build the openjdk for AIX on my AIX system? > > > > Thanks and Regards > > Gordon CY Wu > > Support Engineer|TPS | Automation Products AGS | Applied Materials > Office 801.736.3347| Mobile 801.380.5910 | Support Hot Line > 801.488.2277 > > > > The content of this message is Applied Materials Confidential. If you > are not the intended recipient and have received this message in > error, any use or distribution is prohibited. Please notify me > immediately by reply e-mail and delete this message from your computer system. Thank you. > > P Save a tree. Please don't print this e-mail unless needed. > > > > > ________________________________ > ________________________________ From martin.doerr at sap.com Mon Jun 26 08:44:11 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Jun 2017 08:44:11 +0000 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <20c43bf4-a66b-2cc8-e62f-d58eb66df278@linux.vnet.ibm.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> <20c43bf4-a66b-2cc8-e62f-d58eb66df278@linux.vnet.ibm.com> Message-ID: <0f82ddbcf57348e8ac6e6cd9e51674f3@sap.com> Hi Matt, you can run the pre-push check stand-alone: hg jcheck See: http://openjdk.java.net/projects/code-tools/jcheck/ I just had to add the commit message: 8181809: PPC64: Leverage mtfprd/mffprd on POWER8 Reviewed-by: mdoerr Contributed-by: Matthew Brandyberry (Note that the ':' after the bug id is important.) and replace the Tabs the 2 C1 files to get it passing. (I think that "Illegal tag name" warnings can be ignored.) So only the copyright dates are missing which are not checked by jcheck. But I don't need a new webrev if that's all which needs to be changed. Best regards, Martin -----Original Message----- From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] Sent: Freitag, 23. Juni 2017 18:39 To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 Thanks Martin. Are there tools to help detect formatting errors like the tab characters? I'll keep an eye on this to see if I need to do anything else. -Matt On 6/23/17 4:30 AM, Doerr, Martin wrote: > Excellent. Thanks for the update. The C1 part looks good, too. > > Also, thanks for checking "I could not find evidence of any config that includes vpmsumb but not > mtfprd." > > There are only a few formally required things: > - The new C1 code contains Tab characters. It's not possible to push it without fixing this. > - Copyright messages should be updated. > - Minor resolution to get vm_version_ppc applied to recent jdk10/hs. > > If no other changes get requested, I can handle these issues this time before pushing. > But we need another review, first. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] > Sent: Freitag, 23. Juni 2017 04:54 > To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 > > Updated webrev: http://cr.openjdk.java.net/~gromero/8181809/v2/ > > See below for responses inline. > > On 6/20/17 8:38 AM, Matthew Brandyberry wrote: >> Hi Martin, >> >> Thanks for the review. I'll take a look at these areas and report >> back -- especially the integration into C1. >> >> On 6/20/17 8:33 AM, Doerr, Martin wrote: >>> Hi Matt, >>> >>> thanks for providing this webrev. I had already thought about using >>> these instructions for this purpose and your change matches pretty >>> much what I'd do. >>> >>> Here a couple of comments: >>> ppc.ad: >>> This was a lot of work. Thanks for doing it. >>> effect(DEF dst, USE src); is redundant if a match rule match(Set dst >>> (MoveL2D src)); exists. > Fixed. >>> vm_version: >>> This part is in conflict with Michihiro's change which is already >>> pushed in jdk10, but it's trivial to resolve. I'm ok with using >>> has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble >>> with assuming that a certain Power processor supports all new >>> instructions if it supports certain ones. We also use the hotspot >>> code on as400 where certain instruction subsets were disabled while >>> other Power 8 instructions were usable. Maybe you can double-check if >>> there may exist configurations in which has_vpmsumb() doesn't match >>> has_mtfprd(). > I could not find evidence of any config that includes vpmsumb but not > mtfprd. >>> C1: >>> It should also be possible to use the instructions in C1 compiler. >>> Maybe you would like to take a look at it as well and see if it can >>> be done with feasible effort. >>> Here are some hints: >>> The basic decisions are made in LIRGenerator::do_Convert. You could >>> skip the force_to_spill or must_start_in_memory steps. >>> The final assembly code gets emitted in LIR_Assembler::emit_opConvert >>> where you could replace the store instructions. >>> For testing, you can use -XX:TieredStopAtLevel=1, for example. > Done. Please take a look. >>> Thanks and best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Matthew Brandyberry >>> Sent: Montag, 19. Juni 2017 18:28 >>> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >>> >>> 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. Please review: Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: >>> http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt >>> >>> From thomas.stuefe at gmail.com Mon Jun 26 10:56:55 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 26 Jun 2017 12:56:55 +0200 Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness Message-ID: Hi all, may I please get reviews for this tiny change: Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182864-aix-do-not-assert-in-print-native-callstack/webrev.00/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8182864 In short, this fix removes some asserts from os::print_native_callstack() (via os::Aix::query_stack_dimensions()) which are not really useful. We assert that we do not run on the primordial thread, because otherwise the API used to retrieve the stack dimensions may fail. This is wrong on two accounts: 1) the API now works for the primordial thread too, and does so since AIX 5.3 (?) and 2) this is not the right place to assert for the primordial thread, because the stack trace shall always work. The assert prevented us to get stack traces in some corner cases where we would have been perfectly able to get them. For more background on the primordial thread issue on AIX, please see https://bugs.openjdk.java.net/browse/JDK-8171505 Thanks! Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Jun 26 12:18:26 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 26 Jun 2017 12:18:26 +0000 Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness In-Reply-To: References: Message-ID: Hi Thomas, the changes look good and from what I can read I also think this makes sense? Best regards Christoph From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Montag, 26. Juni 2017 12:57 To: ppc-aix-port-dev at openjdk.java.net Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness Hi all, may I please get reviews for this tiny change: Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182864-aix-do-not-assert-in-print-native-callstack/webrev.00/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8182864 In short, this fix removes some asserts from os::print_native_callstack() (via os::Aix::query_stack_dimensions()) which are not really useful. We assert that we do not run on the primordial thread, because otherwise the API used to retrieve the stack dimensions may fail. This is wrong on two accounts: 1) the API now works for the primordial thread too, and does so since AIX 5.3 (?) and 2) this is not the right place to assert for the primordial thread, because the stack trace shall always work. The assert prevented us to get stack traces in some corner cases where we would have been perfectly able to get them. For more background on the primordial thread issue on AIX, please see https://bugs.openjdk.java.net/browse/JDK-8171505 Thanks! Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Jun 26 12:18:56 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 26 Jun 2017 14:18:56 +0200 Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness In-Reply-To: References: Message-ID: :) Thanks On Mon, Jun 26, 2017 at 2:18 PM, Langer, Christoph wrote: > Hi Thomas, > > > > the changes look good and from what I can read I also think this makes > sense? > > > > Best regards > > Christoph > > > > *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] > *On Behalf Of *Thomas St?fe > *Sent:* Montag, 26. Juni 2017 12:57 > *To:* ppc-aix-port-dev at openjdk.java.net > *Subject:* RFR(xxs): 8182864: [aix] os::print_native_callstack should not > assert for primordial threadness > > > > Hi all, > > > > may I please get reviews for this tiny change: > > > > Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182864-aix-do- > not-assert-in-print-native-callstack/webrev.00/webrev/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8182864 > > > > In short, this fix removes some asserts from os::print_native_callstack() > (via os::Aix::query_stack_dimensions()) which are not really useful. We > assert that we do not run on the primordial thread, because otherwise the > API used to retrieve the stack dimensions may fail. > > > > This is wrong on two accounts: > > 1) the API now works for the primordial thread too, and does so since AIX > 5.3 (?) and > > 2) this is not the right place to assert for the primordial thread, > because the stack trace shall always work. > > > > The assert prevented us to get stack traces in some corner cases where we > would have been perfectly able to get them. > > > > For more background on the primordial thread issue on AIX, please see > https://bugs.openjdk.java.net/browse/JDK-8171505 > > > > Thanks! > > > > Thomas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Mon Jun 26 12:47:45 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Jun 2017 12:47:45 +0000 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <0f82ddbcf57348e8ac6e6cd9e51674f3@sap.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> <20c43bf4-a66b-2cc8-e62f-d58eb66df278@linux.vnet.ibm.com> <0f82ddbcf57348e8ac6e6cd9e51674f3@sap.com> Message-ID: <95d5cb36271e4ebf8398223702b61ac8@sap.com> Hi Matt, after some testing and reviewing the C1 part again, I found 2 bugs: c1_LIRAssembler: is_stack() can't be used for this purpose as the value may be available in a register even though it was forced to stack. I just changed src_in_memory = !VM_Version::has_mtfprd() to make it consistent with LIRGenerator and removed the assertions which have become redundant. c1_LIRGenerator: value.set_destroys_register() is still needed for conversion from FP to GP registers because they kill the src value by fctiwz/fctidz. I just fixed these issues here in a copy of your webrev v2: http://cr.openjdk.java.net/~mdoerr/8181809_ppc64_mtfprd/v2/ Please take a look and use this one for 2nd review. Best regards, Martin -----Original Message----- From: Doerr, Martin Sent: Montag, 26. Juni 2017 10:44 To: 'Matthew Brandyberry' ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RE: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 Hi Matt, you can run the pre-push check stand-alone: hg jcheck See: http://openjdk.java.net/projects/code-tools/jcheck/ I just had to add the commit message: 8181809: PPC64: Leverage mtfprd/mffprd on POWER8 Reviewed-by: mdoerr Contributed-by: Matthew Brandyberry (Note that the ':' after the bug id is important.) and replace the Tabs the 2 C1 files to get it passing. (I think that "Illegal tag name" warnings can be ignored.) So only the copyright dates are missing which are not checked by jcheck. But I don't need a new webrev if that's all which needs to be changed. Best regards, Martin -----Original Message----- From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] Sent: Freitag, 23. Juni 2017 18:39 To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 Thanks Martin. Are there tools to help detect formatting errors like the tab characters? I'll keep an eye on this to see if I need to do anything else. -Matt On 6/23/17 4:30 AM, Doerr, Martin wrote: > Excellent. Thanks for the update. The C1 part looks good, too. > > Also, thanks for checking "I could not find evidence of any config that includes vpmsumb but not > mtfprd." > > There are only a few formally required things: > - The new C1 code contains Tab characters. It's not possible to push it without fixing this. > - Copyright messages should be updated. > - Minor resolution to get vm_version_ppc applied to recent jdk10/hs. > > If no other changes get requested, I can handle these issues this time before pushing. > But we need another review, first. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] > Sent: Freitag, 23. Juni 2017 04:54 > To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 > > Updated webrev: http://cr.openjdk.java.net/~gromero/8181809/v2/ > > See below for responses inline. > > On 6/20/17 8:38 AM, Matthew Brandyberry wrote: >> Hi Martin, >> >> Thanks for the review. I'll take a look at these areas and report >> back -- especially the integration into C1. >> >> On 6/20/17 8:33 AM, Doerr, Martin wrote: >>> Hi Matt, >>> >>> thanks for providing this webrev. I had already thought about using >>> these instructions for this purpose and your change matches pretty >>> much what I'd do. >>> >>> Here a couple of comments: >>> ppc.ad: >>> This was a lot of work. Thanks for doing it. >>> effect(DEF dst, USE src); is redundant if a match rule match(Set dst >>> (MoveL2D src)); exists. > Fixed. >>> vm_version: >>> This part is in conflict with Michihiro's change which is already >>> pushed in jdk10, but it's trivial to resolve. I'm ok with using >>> has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble >>> with assuming that a certain Power processor supports all new >>> instructions if it supports certain ones. We also use the hotspot >>> code on as400 where certain instruction subsets were disabled while >>> other Power 8 instructions were usable. Maybe you can double-check if >>> there may exist configurations in which has_vpmsumb() doesn't match >>> has_mtfprd(). > I could not find evidence of any config that includes vpmsumb but not > mtfprd. >>> C1: >>> It should also be possible to use the instructions in C1 compiler. >>> Maybe you would like to take a look at it as well and see if it can >>> be done with feasible effort. >>> Here are some hints: >>> The basic decisions are made in LIRGenerator::do_Convert. You could >>> skip the force_to_spill or must_start_in_memory steps. >>> The final assembly code gets emitted in LIR_Assembler::emit_opConvert >>> where you could replace the store instructions. >>> For testing, you can use -XX:TieredStopAtLevel=1, for example. > Done. Please take a look. >>> Thanks and best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Matthew Brandyberry >>> Sent: Montag, 19. Juni 2017 18:28 >>> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >>> >>> 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. Please review: Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: >>> http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt >>> >>> From martin.doerr at sap.com Mon Jun 26 13:31:01 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Jun 2017 13:31:01 +0000 Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness In-Reply-To: References: Message-ID: Hi Thomas, reviewed. I?m fine with it because the real issues wrt. primordial thread on AIX will be addressed in JDK-8171505. Fixing native stack traces makes sense. Thanks for doing it. Best regards, Martin From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph Sent: Montag, 26. Juni 2017 14:18 To: Thomas St?fe Cc: ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness Hi Thomas, the changes look good and from what I can read I also think this makes sense? Best regards Christoph From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Montag, 26. Juni 2017 12:57 To: ppc-aix-port-dev at openjdk.java.net Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness Hi all, may I please get reviews for this tiny change: Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182864-aix-do-not-assert-in-print-native-callstack/webrev.00/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8182864 In short, this fix removes some asserts from os::print_native_callstack() (via os::Aix::query_stack_dimensions()) which are not really useful. We assert that we do not run on the primordial thread, because otherwise the API used to retrieve the stack dimensions may fail. This is wrong on two accounts: 1) the API now works for the primordial thread too, and does so since AIX 5.3 (?) and 2) this is not the right place to assert for the primordial thread, because the stack trace shall always work. The assert prevented us to get stack traces in some corner cases where we would have been perfectly able to get them. For more background on the primordial thread issue on AIX, please see https://bugs.openjdk.java.net/browse/JDK-8171505 Thanks! Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Jun 26 13:33:56 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 26 Jun 2017 15:33:56 +0200 Subject: RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness In-Reply-To: References: Message-ID: Thank you Martin! On Mon, Jun 26, 2017 at 3:31 PM, Doerr, Martin wrote: > Hi Thomas, > > > > reviewed. I?m fine with it because the real issues wrt. primordial thread > on AIX will be addressed in JDK-8171505. > > Fixing native stack traces makes sense. Thanks for doing it. > > > > Best regards, > > Martin > > > > > > *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] > *On Behalf Of *Langer, Christoph > *Sent:* Montag, 26. Juni 2017 14:18 > *To:* Thomas St?fe > *Cc:* ppc-aix-port-dev at openjdk.java.net > *Subject:* RE: RFR(xxs): 8182864: [aix] os::print_native_callstack should > not assert for primordial threadness > > > > Hi Thomas, > > > > the changes look good and from what I can read I also think this makes > sense? > > > > Best regards > > Christoph > > > > *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net > ] *On Behalf Of *Thomas St?fe > *Sent:* Montag, 26. Juni 2017 12:57 > *To:* ppc-aix-port-dev at openjdk.java.net > *Subject:* RFR(xxs): 8182864: [aix] os::print_native_callstack should not > assert for primordial threadness > > > > Hi all, > > > > may I please get reviews for this tiny change: > > > > Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182864-aix-do- > not-assert-in-print-native-callstack/webrev.00/webrev/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8182864 > > > > In short, this fix removes some asserts from os::print_native_callstack() > (via os::Aix::query_stack_dimensions()) which are not really useful. We > assert that we do not run on the primordial thread, because otherwise the > API used to retrieve the stack dimensions may fail. > > > > This is wrong on two accounts: > > 1) the API now works for the primordial thread too, and does so since AIX > 5.3 (?) and > > 2) this is not the right place to assert for the primordial thread, > because the stack trace shall always work. > > > > The assert prevented us to get stack traces in some corner cases where we > would have been perfectly able to get them. > > > > For more background on the primordial thread issue on AIX, please see > https://bugs.openjdk.java.net/browse/JDK-8171505 > > > > Thanks! > > > > Thomas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From OGATAK at jp.ibm.com Tue Jun 27 05:12:44 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 14:12:44 +0900 Subject: RFR: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Message-ID: Hi all, please review a change for JDK-8182743. Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ This change removes a "volatile" qualifier of a static variable used by Charset.atBugLevel() because it does not improve thread-safety of the code and it hurts performance on PPC (and should be the same in ARM, too). Removing the "volatile" improved performance by 26% in a POWER8 machine using following micro benchmark: ------ import java.io.*; import java.nio.ByteBuffer; import java.nio.charset.Charset; import java.util.ArrayList; class ConvertTest { static String str; public static void main(String[] args) { byte buf[] = { 0x41 }; Charset fromCharset = Charset.forName("iso-8859-1"); long start = System.currentTimeMillis(); for(long i = 0; i < 100000000; i++) str = new String(buf, 0, 1, fromCharset); long end = System.currentTimeMillis(); System.out.println("Elapsed: "+(end-start)+" ms"); } } ------ Regards, Ogata From christoph.langer at sap.com Tue Jun 27 06:50:24 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 27 Jun 2017 06:50:24 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: Message-ID: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Hi Ogata, I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially affects all platforms and should be discussed there. As for your proposal: I can generally understand that using volatile at this place hurts performance on the power platform and this should be improved. I however don't fully oversee if just removing the volatile qualifier is the only thing to do here. Maybe one should implement some double checked locking pattern around the static field bugLevel and its initialization from system properties? I guess during VM initialization multiple threads can got to this place and the volatile qualifier was added for synchronizing access to "bugLevel". So, waiting for comments from other experts... Best regards Christoph > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Kazunori Ogata > Sent: Dienstag, 27. Juni 2017 07:13 > To: jdk10-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RFR: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi all, please review a change for JDK-8182743. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > This change removes a "volatile" qualifier of a static variable used by > Charset.atBugLevel() because it does not improve thread-safety of the code > and it hurts performance on PPC (and should be the same in ARM, too). > Removing the "volatile" improved performance by 26% in a POWER8 machine > using following micro benchmark: > > ------ > import java.io.*; > import java.nio.ByteBuffer; > import java.nio.charset.Charset; > import java.util.ArrayList; > > class ConvertTest { > static String str; > > public static void main(String[] args) { > byte buf[] = { 0x41 }; > Charset fromCharset = Charset.forName("iso-8859-1"); > > long start = System.currentTimeMillis(); > > for(long i = 0; i < 100000000; i++) > str = new String(buf, 0, 1, fromCharset); > > long end = System.currentTimeMillis(); > > System.out.println("Elapsed: "+(end-start)+" ms"); > } > } > ------ > > > Regards, > Ogata From Alan.Bateman at oracle.com Tue Jun 27 07:01:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 08:01:25 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Message-ID: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> On 27/06/2017 07:50, Langer, Christoph wrote: > Hi Ogata, > > I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially affects all platforms and should be discussed there. > > As for your proposal: I can generally understand that using volatile at this place hurts performance on the power platform and this should be improved. I however don't fully oversee if just removing the volatile qualifier is the only thing to do here. Maybe one should implement some double checked locking pattern around the static field bugLevel and its initialization from system properties? I guess during VM initialization multiple threads can got to this place and the volatile qualifier was added for synchronizing access to "bugLevel". > It could be changed to be a final field in a holder class. It might be better if we can just remove the test from Charset.checkName as I think that dates back to an incompatible change going from JDK 1.4 to JDK 5 that should no longer be a concern. -Alan From claes.redestad at oracle.com Tue Jun 27 07:36:20 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Jun 2017 09:36:20 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: On 2017-06-27 09:01, Alan Bateman wrote: > It might be better if we can just remove the test from > Charset.checkName as I think that dates back to an incompatible change > going from JDK 1.4 to JDK 5 that should no longer be a concern. The check of Charset.atBugLevel in checkName should no longer happen for the majority of situations, as that test is now only done if the charset name is "" (see https://bugs.openjdk.java.net/browse/JDK-8174831), since what differs between 1.4 and 1.5 was apparently whether or not the empty string was to be accepted as a valid Charset... So yes, if we can get rid of the test altogether, we'll be even better off! /Claes From OGATAK at jp.ibm.com Tue Jun 27 08:12:45 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:12:45 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Message-ID: Hi Christoph, Thank you for redirecting this request to appropriate mailing lists. Hi Aleksey, Thank you for reviewing the patch. Regards, Ogata Aleksey Shipilev wrote on 2017/06/27 15:58:56: > From: Aleksey Shipilev > To: "Langer, Christoph" , Kazunori Ogata > , core-libs-dev , "nio- > dev at openjdk.java.net" > Cc: "ppc-aix-port-dev at openjdk.java.net" > Date: 2017/06/27 15:59 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 06/27/2017 08:50 AM, Langer, Christoph wrote: > > So, waiting for comments from other experts... > > >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > This patch is fine as stated. > > Without volatile, there is a benign data race on the bugLevel field, which is > okay, assuming "sun.nio.cs.bugLevel" never actually changes. Doing > double-checked-locking seems excessive here, because we can accept more than one > invocation of privilegedGetProperty. > > -Aleksey > > > > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From Alan.Bateman at oracle.com Tue Jun 27 08:13:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 09:13:19 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> On 27/06/2017 08:36, Claes Redestad wrote: > > The check of Charset.atBugLevel in checkName should no longer happen > for the majority of situations, as that test is now only done if the > charset name is "" (see > https://bugs.openjdk.java.net/browse/JDK-8174831), Kazunori's mail didn't mention the JDK build he is using, it may have been JDK 8 rather than JDK 9. > since what differs between 1.4 and 1.5 was apparently whether or not > the empty string was to be accepted as a valid Charset... > > So yes, if we can get rid of the test altogether, we'll be even better > off! JDK-4786884 is the original issue. If there was any code dependent on the broken behavior in 1.4 then I would expect it should have been fixed by now. So I think it can be removed. -Alan From OGATAK at jp.ibm.com Tue Jun 27 08:31:21 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:31:21 +0900 Subject: Fw: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Message-ID: Hi, I'm re-posting this mail because I sent the old one before I subscribe core-libs-dev and nio-dev. Sorry if you receive this mail twice. Regards, Ogata ----- Forwarded by Kazunori Ogata/Japan/IBM on 2017/06/27 17:28 ----- "ppc-aix-port-dev" wrote on 2017/06/27 17:12:45: > From: "Kazunori Ogata" > To: Aleksey Shipilev > Cc: core-libs-dev , "nio- > dev at openjdk.java.net" , "ppc-aix-port- > dev at openjdk.java.net" > Date: 2017/06/27 17:13 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > Sent by: "ppc-aix-port-dev" > > Hi Christoph, > > Thank you for redirecting this request to appropriate mailing lists. > > > Hi Aleksey, > > Thank you for reviewing the patch. > > > Regards, > Ogata > > > Aleksey Shipilev wrote on 2017/06/27 15:58:56: > > > From: Aleksey Shipilev > > To: "Langer, Christoph" , Kazunori Ogata > > , core-libs-dev , > "nio- > > dev at openjdk.java.net" > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > > Date: 2017/06/27 15:59 > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > On 06/27/2017 08:50 AM, Langer, Christoph wrote: > > > So, waiting for comments from other experts... > > > > >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > > > This patch is fine as stated. > > > > Without volatile, there is a benign data race on the bugLevel field, > which is > > okay, assuming "sun.nio.cs.bugLevel" never actually changes. Doing > > double-checked-locking seems excessive here, because we can accept more > than one > > invocation of privilegedGetProperty. > > > > -Aleksey > > > > > > > > > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] > From OGATAK at jp.ibm.com Tue Jun 27 08:34:46 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:34:46 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: Alan Bateman wrote on 2017/06/27 16:01:25: > From: Alan Bateman > To: "Langer, Christoph" , Kazunori Ogata > , core-libs-dev , "nio- > dev at openjdk.java.net" > Cc: "ppc-aix-port-dev at openjdk.java.net" > Date: 2017/06/27 16:01 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 07:50, Langer, Christoph wrote: > > Hi Ogata, > > > > I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially > affects all platforms and should be discussed there. > > > > As for your proposal: I can generally understand that using volatile at > this place hurts performance on the power platform and this should be > improved. I however don't fully oversee if just removing the volatile > qualifier is the only thing to do here. Maybe one should implement some > double checked locking pattern around the static field bugLevel and its > initialization from system properties? I guess during VM initialization > multiple threads can got to this place and the volatile qualifier was > added for synchronizing access to "bugLevel". > > > It could be changed to be a final field in a holder class. The code looks that it doesn't use final intentionally because it postpones setting set bugLevel until VM.isBooted() returns true, though I'm not sure if the value of privilegedGetProperty() can change during a bootstrap of JVM. ----- 289: if (!VM.isBooted()) 290: return false; ----- > It might be > better if we can just remove the test from Charset.checkName as I think > that dates back to an incompatible change going from JDK 1.4 to JDK 5 > that should no longer be a concern. > > -Alan > From OGATAK at jp.ibm.com Tue Jun 27 08:39:10 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:39:10 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> Message-ID: Hi Alan, I'm working on the JDK 10 source code, but I verified JDK 8 has the same code w.r.t. use of volatile. Regards, Ogata Alan Bateman wrote on 2017/06/27 17:13:19: > From: Alan Bateman > To: Claes Redestad , "Langer, Christoph" > , Kazunori Ogata , core-libs- > dev , "nio-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "ppc-aix-port-dev at openjdk.java.net" > Date: 2017/06/27 17:13 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > The check of Charset.atBugLevel in checkName should no longer happen > > for the majority of situations, as that test is now only done if the > > charset name is "" (see > > https://bugs.openjdk.java.net/browse/JDK-8174831), > Kazunori's mail didn't mention the JDK build he is using, it may have > been JDK 8 rather than JDK 9. > > > since what differs between 1.4 and 1.5 was apparently whether or not > > the empty string was to be accepted as a valid Charset... > > > > So yes, if we can get rid of the test altogether, we'll be even better > > off! > JDK-4786884 is the original issue. If there was any code dependent on > the broken behavior in 1.4 then I would expect it should have been fixed > by now. So I think it can be removed. > > -Alan > From sean.coffey at oracle.com Tue Jun 27 08:40:06 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 27 Jun 2017 09:40:06 +0100 Subject: RFR: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: Message-ID: This should be reviewed on nio-dev. Please drop jdk10-dev on reply. The atBugLevel(String) method seems to be more for legacy use from JDK 1.4/1.5 family. Maybe it's time to drop its use? We'd need to check if the VM.isBooted() call is still necessary. regards, Sean. On 27/06/2017 06:12, Kazunori Ogata wrote: > Hi all, please review a change for JDK-8182743. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > This change removes a "volatile" qualifier of a static variable used by > Charset.atBugLevel() because it does not improve thread-safety of the code > and it hurts performance on PPC (and should be the same in ARM, too). > Removing the "volatile" improved performance by 26% in a POWER8 machine > using following micro benchmark: > > ------ > import java.io.*; > import java.nio.ByteBuffer; > import java.nio.charset.Charset; > import java.util.ArrayList; > > class ConvertTest { > static String str; > > public static void main(String[] args) { > byte buf[] = { 0x41 }; > Charset fromCharset = Charset.forName("iso-8859-1"); > > long start = System.currentTimeMillis(); > > for(long i = 0; i < 100000000; i++) > str = new String(buf, 0, 1, fromCharset); > > long end = System.currentTimeMillis(); > > System.out.println("Elapsed: "+(end-start)+" ms"); > } > } > ------ > > > Regards, > Ogata > From OGATAK at jp.ibm.com Tue Jun 27 08:48:54 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 27 Jun 2017 17:48:54 +0900 Subject: RFR: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: Message-ID: Hi Sean, Thank you for your suggestion. Langer, Christoph has gave me the same comment and redirected the RFR to core-libs-dev and nio-dev. Sorry for not telling it here jdk10-dev earlier. Regards, Ogata Se?n Coffey wrote on 2017/06/27 17:40:06: > From: Se?n Coffey > To: Kazunori Ogata , ppc-aix-port-dev at openjdk.java.net, > nio-dev at openjdk.java.net > Cc: jdk10-dev at openjdk.java.net > Date: 2017/06/27 17:40 > Subject: Re: RFR: 8179527: Ineffective use of volatile hurts performance > of Charset.atBugLevel() > > This should be reviewed on nio-dev. Please drop jdk10-dev on reply. > > The atBugLevel(String) method seems to be more for legacy use from JDK > 1.4/1.5 family. Maybe it's time to drop its use? We'd need to check if > the VM.isBooted() call is still necessary. > > regards, > Sean. > > On 27/06/2017 06:12, Kazunori Ogata wrote: > > Hi all, please review a change for JDK-8182743. > > > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 > > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > > > This change removes a "volatile" qualifier of a static variable used by > > Charset.atBugLevel() because it does not improve thread-safety of the code > > and it hurts performance on PPC (and should be the same in ARM, too). > > Removing the "volatile" improved performance by 26% in a POWER8 machine > > using following micro benchmark: > > > > ------ > > import java.io.*; > > import java.nio.ByteBuffer; > > import java.nio.charset.Charset; > > import java.util.ArrayList; > > > > class ConvertTest { > > static String str; > > > > public static void main(String[] args) { > > byte buf[] = { 0x41 }; > > Charset fromCharset = Charset.forName("iso-8859-1"); > > > > long start = System.currentTimeMillis(); > > > > for(long i = 0; i < 100000000; i++) > > str = new String(buf, 0, 1, fromCharset); > > > > long end = System.currentTimeMillis(); > > > > System.out.println("Elapsed: "+(end-start)+" ms"); > > } > > } > > ------ > > > > > > Regards, > > Ogata > > > From Alan.Bateman at oracle.com Tue Jun 27 11:25:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jun 2017 12:25:18 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> Message-ID: <28ef06c9-c89c-02f4-58e1-3f47a705101b@oracle.com> On 27/06/2017 09:34, Kazunori Ogata wrote: > : > The code looks that it doesn't use final intentionally because it > postpones setting set bugLevel until VM.isBooted() returns true, though > I'm not sure if the value of privilegedGetProperty() can change during a > bootstrap of JVM. > ----- > 289: if (!VM.isBooted()) > 290: return false; > ----- > I think we can remove the atBugLevel check from Charset.checkName and also the CharsetEncoder/CharsetDecoder constructors. -Alan From Gordon_CY_Wu at amat.com Tue Jun 27 17:05:43 2017 From: Gordon_CY_Wu at amat.com (Gordon_CY_Wu at amat.com) Date: Tue, 27 Jun 2017 17:05:43 +0000 Subject: Failed to download the bootstrap JDK In-Reply-To: References: Message-ID: Hi Volker, Urvin Shah is going to responsible for the openjdk task in the team. I include him in this email. Please give him the same access that I have to him as well. Thanks and Regards -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Thursday, June 22, 2017 10:10 AM To: Gordon CY Wu Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: Failed to download the bootstrap JDK Hi Gordon, the AIX bootstrap jdk you mention is pretty old and unfortunately not availabl any more due to a crash on the server which used to provide it. The Adopt OpenJDK group is currently running an effort to create a continuous OpenJDK build on all OpenJDK platforms. They have a slack group [2] and I've just send you an invitation for it. In the #aix channel of that group I've recently posted an openjdk7 build which you can use as boot jdk on AIX. Regards, Volker [1] https://wiki.openjdk.java.net/display/Adoption/Main [2] https://adoptopenjdk.slack.com On Thu, Jun 22, 2017 at 3:22 AM, wrote: > Hi, All > > > > I am trying to download the bootstrap JDK ( > openjdk1.7.0-ppc-aix-port-aix-ppc64-b03.tar.bz2 > openjdk_8u40_b13-aix-ppc64.tar.bz2. ) following the link from > http://cr.openjdk.java.net/~simonis/ppc-aix-port, but did not succeed. > > Are those files still existed? Where can I download the files, so I > can build the openjdk for AIX on my AIX system? > > > > Thanks and Regards > > Gordon CY Wu > > Support Engineer|TPS | Automation Products AGS | Applied Materials > Office 801.736.3347| Mobile 801.380.5910 | Support Hot Line > 801.488.2277 > > > > The content of this message is Applied Materials Confidential. If you > are not the intended recipient and have received this message in > error, any use or distribution is prohibited. Please notify me > immediately by reply e-mail and delete this message from your computer system. Thank you. > > P Save a tree. Please don't print this e-mail unless needed. > > > > > ________________________________ > ________________________________ From christoph.langer at sap.com Tue Jun 27 18:32:51 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 27 Jun 2017 18:32:51 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> Message-ID: <9a235816b1544dd587a1e6d2268e6407@sap.com> Hi Ogata, I think I agree with Alan that the Charset.atBugLevel() method can completely be eliminated from java/nio/charset. Ogata, would you respin your change to remove it and post it for review? I can then sponsor it for you. @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? Best regards Christoph > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Dienstag, 27. Juni 2017 10:13 > To: Claes Redestad ; Langer, Christoph > ; Kazunori Ogata ; > core-libs-dev ; nio-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > The check of Charset.atBugLevel in checkName should no longer happen > > for the majority of situations, as that test is now only done if the > > charset name is "" (see > > https://bugs.openjdk.java.net/browse/JDK-8174831), > Kazunori's mail didn't mention the JDK build he is using, it may have > been JDK 8 rather than JDK 9. > > > since what differs between 1.4 and 1.5 was apparently whether or not > > the empty string was to be accepted as a valid Charset... > > > > So yes, if we can get rid of the test altogether, we'll be even better > > off! > JDK-4786884 is the original issue. If there was any code dependent on > the broken behavior in 1.4 then I would expect it should have been fixed > by now. So I think it can be removed. > > -Alan From shade at redhat.com Tue Jun 27 06:58:56 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Jun 2017 08:58:56 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> Message-ID: On 06/27/2017 08:50 AM, Langer, Christoph wrote: > So, waiting for comments from other experts... >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ This patch is fine as stated. Without volatile, there is a benign data race on the bugLevel field, which is okay, assuming "sun.nio.cs.bugLevel" never actually changes. Doing double-checked-locking seems excessive here, because we can accept more than one invocation of privilegedGetProperty. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From OGATAK at jp.ibm.com Wed Jun 28 06:20:53 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 15:20:53 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <9a235816b1544dd587a1e6d2268e6407@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: Hi Christoph, Thank you for your suggestions and offering to sponsor my changes. Here is the updated webrev that removes the atBugLevel() definition in Charset.java and its call sites in Charset.java and Charset-X-Coder.java.template. Please review this: http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 03:32:51: > From: "Langer, Christoph" > To: Alan Bateman , Kazunori Ogata > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Claes Redestad , core- > libs-dev , "nio-dev at openjdk.java.net" > > Date: 2017/06/28 03:32 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > I think I agree with Alan that the Charset.atBugLevel() method can > completely be eliminated from java/nio/charset. > > Ogata, would you respin your change to remove it and post it for review? I > can then sponsor it for you. > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > here since support for "sun.nio.cs.bugLevel" will be removed? > > Best regards > Christoph > > > -----Original Message----- > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > Sent: Dienstag, 27. Juni 2017 10:13 > > To: Claes Redestad ; Langer, Christoph > > ; Kazunori Ogata ; > > core-libs-dev ; nio-dev at openjdk.java.net > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > > > The check of Charset.atBugLevel in checkName should no longer happen > > > for the majority of situations, as that test is now only done if the > > > charset name is "" (see > > > https://bugs.openjdk.java.net/browse/JDK-8174831), > > Kazunori's mail didn't mention the JDK build he is using, it may have > > been JDK 8 rather than JDK 9. > > > > > since what differs between 1.4 and 1.5 was apparently whether or not > > > the empty string was to be accepted as a valid Charset... > > > > > > So yes, if we can get rid of the test altogether, we'll be even better > > > off! > > JDK-4786884 is the original issue. If there was any code dependent on > > the broken behavior in 1.4 then I would expect it should have been fixed > > by now. So I think it can be removed. > > > > -Alan From christoph.langer at sap.com Wed Jun 28 06:45:41 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 06:45:41 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: <587313ab0dcf483abb3eb300bc779695@sap.com> Hi Ogata, this looks fine. The copyright year in Charset-X-Coder.java.template needs to be updated, but I can do that when I push it. Waiting for another review... Best regards Christoph > -----Original Message----- > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > Sent: Mittwoch, 28. Juni 2017 08:21 > To: Langer, Christoph > Cc: Alan Bateman ; Claes Redestad > ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Christoph, > > Thank you for your suggestions and offering to sponsor my changes. > > Here is the updated webrev that removes the atBugLevel() definition in > Charset.java and its call sites in Charset.java and > Charset-X-Coder.java.template. Please review this: > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 03:32:51: > > > From: "Langer, Christoph" > > To: Alan Bateman , Kazunori Ogata > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, Claes Redestad , > core- > > libs-dev , "nio-dev at openjdk.java.net" > > > > Date: 2017/06/28 03:32 > > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi Ogata, > > > > I think I agree with Alan that the Charset.atBugLevel() method can > > completely be eliminated from java/nio/charset. > > > > Ogata, would you respin your change to remove it and post it for review? > I > > can then sponsor it for you. > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > > here since support for "sun.nio.cs.bugLevel" will be removed? > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > > Sent: Dienstag, 27. Juni 2017 10:13 > > > To: Claes Redestad ; Langer, Christoph > > > ; Kazunori Ogata ; > > > core-libs-dev ; > nio-dev at openjdk.java.net > > > Cc: ppc-aix-port-dev at openjdk.java.net > > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > > > > > The check of Charset.atBugLevel in checkName should no longer > happen > > > > for the majority of situations, as that test is now only done if the > > > > charset name is "" (see > > > > https://bugs.openjdk.java.net/browse/JDK-8174831), > > > Kazunori's mail didn't mention the JDK build he is using, it may have > > > been JDK 8 rather than JDK 9. > > > > > > > since what differs between 1.4 and 1.5 was apparently whether or not > > > > the empty string was to be accepted as a valid Charset... > > > > > > > > So yes, if we can get rid of the test altogether, we'll be even > better > > > > off! > > > JDK-4786884 is the original issue. If there was any code dependent on > > > the broken behavior in 1.4 then I would expect it should have been > fixed > > > by now. So I think it can be removed. > > > > > > -Alan > From OGATAK at jp.ibm.com Wed Jun 28 06:50:45 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 15:50:45 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <587313ab0dcf483abb3eb300bc779695@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <587313ab0dcf483abb3eb300bc779695@sap.com> Message-ID: Thank you, Christoph. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 15:45:41: > From: "Langer, Christoph" > To: Kazunori Ogata > Cc: Alan Bateman , Claes Redestad > , core-libs-dev dev at openjdk.java.net>, "nio-dev at openjdk.java.net" dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net> > Date: 2017/06/28 15:45 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > this looks fine. > > The copyright year in Charset-X-Coder.java.template needs to be updated, > but I can do that when I push it. > > Waiting for another review... > > Best regards > Christoph > > > -----Original Message----- > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > > Sent: Mittwoch, 28. Juni 2017 08:21 > > To: Langer, Christoph > > Cc: Alan Bateman ; Claes Redestad > > ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi Christoph, > > > > Thank you for your suggestions and offering to sponsor my changes. > > > > Here is the updated webrev that removes the atBugLevel() definition in > > Charset.java and its call sites in Charset.java and > > Charset-X-Coder.java.template. Please review this: > > > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > > > > Regards, > > Ogata > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > 03:32:51: > > > > > From: "Langer, Christoph" > > > To: Alan Bateman , Kazunori Ogata > > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > dev at openjdk.java.net>, Claes Redestad , > > core- > > > libs-dev , "nio-dev at openjdk.java.net" > > > > > > Date: 2017/06/28 03:32 > > > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > Hi Ogata, > > > > > > I think I agree with Alan that the Charset.atBugLevel() method can > > > completely be eliminated from java/nio/charset. > > > > > > Ogata, would you respin your change to remove it and post it for review? > > I > > > can then sponsor it for you. > > > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > > > > here since support for "sun.nio.cs.bugLevel" will be removed? > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > > > Sent: Dienstag, 27. Juni 2017 10:13 > > > > To: Claes Redestad ; Langer, Christoph > > > > ; Kazunori Ogata ; > > > > core-libs-dev ; > > nio-dev at openjdk.java.net > > > > Cc: ppc-aix-port-dev at openjdk.java.net > > > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > > > Charset.atBugLevel() > > > > > > > > On 27/06/2017 08:36, Claes Redestad wrote: > > > > > > > > > > The check of Charset.atBugLevel in checkName should no longer > > happen > > > > > for the majority of situations, as that test is now only done if the > > > > > charset name is "" (see > > > > > https://bugs.openjdk.java.net/browse/JDK-8174831), > > > > Kazunori's mail didn't mention the JDK build he is using, it may have > > > > been JDK 8 rather than JDK 9. > > > > > > > > > since what differs between 1.4 and 1.5 was apparently whether or not > > > > > the empty string was to be accepted as a valid Charset... > > > > > > > > > > So yes, if we can get rid of the test altogether, we'll be even > > better > > > > > off! > > > > JDK-4786884 is the original issue. If there was any code dependent on > > > > the broken behavior in 1.4 then I would expect it should have been > > fixed > > > > by now. So I think it can be removed. > > > > > > > > -Alan > > > From christoph.langer at sap.com Wed Jun 28 08:47:41 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 08:47:41 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: <38ffe8c4e4b44dd9994d743f17985667@sap.com> Hi Petar, thanks for pointing out the need for the CSR, I thought so too. I?ll run through the CSR process? It?ll probably be an interesting learning experience for me as well ? Best regards Christoph From: Peter Levart [mailto:peter.levart at gmail.com] Sent: Mittwoch, 28. Juni 2017 10:45 To: Kazunori Ogata ; Langer, Christoph Cc: ppc-aix-port-dev at openjdk.java.net; core-libs-dev ; nio-dev at openjdk.java.net Subject: Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Hi Ogata, The change looks good. But I think this needs to go through CSR. The CSR FAQ page at: https://wiki.openjdk.java.net/display/csr/CSR+FAQs writes... Q: What sort of changes require CSR review? A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR review. In this context "interface" isn't limited to the Java programing language definition of an interface, but encompasses the broader concept of a protocol between the JDK and users of the JDK. Examples of interfaces by this definition include: ... Changing or defining a new system or security property The FAQ also writes: Q: How do I create a CSR ? A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain. Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports. Since Christoph has already volunteered to be your sponsor, you could ask him to file the CSR for you. Or I can volunteer to file it (and learn how this goes) if Christoph doesn't have the time. It's Christophs call... Regards, Peter On 06/28/2017 08:20 AM, Kazunori Ogata wrote: Hi Christoph, Thank you for your suggestions and offering to sponsor my changes. Here is the updated webrev that removes the atBugLevel() definition in Charset.java and its call sites in Charset.java and Charset-X-Coder.java.template. Please review this: http://cr.openjdk.java.net/~horii/8179527/webrev.01/ Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 03:32:51: From: "Langer, Christoph" To: Alan Bateman , Kazunori Ogata Cc: "ppc-aix-port-dev at openjdk.java.net" >, Claes Redestad , core- libs-dev , "nio-dev at openjdk.java.net" Date: 2017/06/28 03:32 Subject: RE: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() Hi Ogata, I think I agree with Alan that the Charset.atBugLevel() method can completely be eliminated from java/nio/charset. Ogata, would you respin your change to remove it and post it for review? I can then sponsor it for you. @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? Best regards Christoph -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Dienstag, 27. Juni 2017 10:13 To: Claes Redestad ; Langer, Christoph ; Kazunori Ogata ; core-libs-dev ; nio-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() On 27/06/2017 08:36, Claes Redestad wrote: The check of Charset.atBugLevel in checkName should no longer happen for the majority of situations, as that test is now only done if the charset name is "" (see https://bugs.openjdk.java.net/browse/JDK-8174831), Kazunori's mail didn't mention the JDK build he is using, it may have been JDK 8 rather than JDK 9. since what differs between 1.4 and 1.5 was apparently whether or not the empty string was to be accepted as a valid Charset... So yes, if we can get rid of the test altogether, we'll be even better off! JDK-4786884 is the original issue. If there was any code dependent on the broken behavior in 1.4 then I would expect it should have been fixed by now. So I think it can be removed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jun 28 08:57:57 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 28 Jun 2017 10:57:57 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <587313ab0dcf483abb3eb300bc779695@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <587313ab0dcf483abb3eb300bc779695@sap.com> Message-ID: Looks good to me, pending CSR approval. Additionally, maybe this is a good opportunity to re-examine the very similarly implemented sun.nio.ch.bugLevel used in sun.nio.ch.Util and sun.nio.ch.SelectorImpl? As a separate bug, of course. /Claes On 2017-06-28 08:45, Langer, Christoph wrote: > Hi Ogata, > > this looks fine. > > The copyright year in Charset-X-Coder.java.template needs to be updated, but I can do that when I push it. > > Waiting for another review... > > Best regards > Christoph > >> -----Original Message----- >> From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] >> Sent: Mittwoch, 28. Juni 2017 08:21 >> To: Langer, Christoph >> Cc: Alan Bateman ; Claes Redestad >> ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- >> dev at openjdk.java.net >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >> Charset.atBugLevel() >> >> Hi Christoph, >> >> Thank you for your suggestions and offering to sponsor my changes. >> >> Here is the updated webrev that removes the atBugLevel() definition in >> Charset.java and its call sites in Charset.java and >> Charset-X-Coder.java.template. Please review this: >> >> http://cr.openjdk.java.net/~horii/8179527/webrev.01/ >> >> >> Regards, >> Ogata >> >> >> "Langer, Christoph" wrote on 2017/06/28 >> 03:32:51: >> >>> From: "Langer, Christoph" >>> To: Alan Bateman , Kazunori Ogata >> >>> Cc: "ppc-aix-port-dev at openjdk.java.net" >> dev at openjdk.java.net>, Claes Redestad , >> core- >>> libs-dev , "nio-dev at openjdk.java.net" >>> >>> Date: 2017/06/28 03:32 >>> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >>> Charset.atBugLevel() >>> >>> Hi Ogata, >>> >>> I think I agree with Alan that the Charset.atBugLevel() method can >>> completely be eliminated from java/nio/charset. >>> >>> Ogata, would you respin your change to remove it and post it for review? >> I >>> can then sponsor it for you. >>> >>> @Alan: Do we need a CSR ("Compatibility & Specification Review") request >>> here since support for "sun.nio.cs.bugLevel" will be removed? >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>>> Sent: Dienstag, 27. Juni 2017 10:13 >>>> To: Claes Redestad ; Langer, Christoph >>>> ; Kazunori Ogata ; >>>> core-libs-dev ; >> nio-dev at openjdk.java.net >>>> Cc: ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: 8179527: Ineffective use of volatile hurts performance of >>>> Charset.atBugLevel() >>>> >>>> On 27/06/2017 08:36, Claes Redestad wrote: >>>>> The check of Charset.atBugLevel in checkName should no longer >> happen >>>>> for the majority of situations, as that test is now only done if the >>>>> charset name is "" (see >>>>> https://bugs.openjdk.java.net/browse/JDK-8174831), >>>> Kazunori's mail didn't mention the JDK build he is using, it may have >>>> been JDK 8 rather than JDK 9. >>>> >>>>> since what differs between 1.4 and 1.5 was apparently whether or not >>>>> the empty string was to be accepted as a valid Charset... >>>>> >>>>> So yes, if we can get rid of the test altogether, we'll be even >> better >>>>> off! >>>> JDK-4786884 is the original issue. If there was any code dependent on >>>> the broken behavior in 1.4 then I would expect it should have been >> fixed >>>> by now. So I think it can be removed. >>>> >>>> -Alan From Alan.Bateman at oracle.com Wed Jun 28 09:00:06 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Jun 2017 10:00:06 +0100 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <9a235816b1544dd587a1e6d2268e6407@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> On 27/06/2017 19:32, Langer, Christoph wrote: > : > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request here since support for "sun.nio.cs.bugLevel" will be removed? > This system property pre-dates OpenJDK but it would have had a CCC at the time. So creating a CSR to indicate that it can no longer be used to get to JDK 1.4 behavior would be good. Thanks. -Alan From christoph.langer at sap.com Wed Jun 28 09:23:43 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 09:23:43 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: Hi, I just filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8183116. I set it to status "Proposed". I assume it will be handled by the csr group automatically? As for the patch: I just recognized that we'll need to update the tests jdk/test/java/nio/charset/Charset/EmptyCharsetName.java and jdk/test/java/nio/charset/CharsetDecoder/AverageMax.java if we remove "sun.nio.cs.bugLevel". E.g. remove the second run with -Dsun.nio.cs.bugLevel=1.4 and clean the code for that. @Ogata: Can you please do that? You might chose to wait until the CSR process is done... Best regards Christoph PS: The bug is https://bugs.openjdk.java.net/browse/JDK-8182743, not 8179527, as the Subject indicates. > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Mittwoch, 28. Juni 2017 11:00 > To: Langer, Christoph ; Kazunori Ogata > > Cc: ppc-aix-port-dev at openjdk.java.net; Claes Redestad > ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > > > On 27/06/2017 19:32, Langer, Christoph wrote: > > : > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > here since support for "sun.nio.cs.bugLevel" will be removed? > > > This system property pre-dates OpenJDK but it would have had a CCC at > the time. So creating a CSR to indicate that it can no longer be used to > get to JDK 1.4 behavior would be good. Thanks. > > -Alan From OGATAK at jp.ibm.com Wed Jun 28 09:27:29 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 18:27:29 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <38ffe8c4e4b44dd9994d743f17985667@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <38ffe8c4e4b44dd9994d743f17985667@sap.com> Message-ID: Hi Christoph, Thank you for helping me on the CSR. Hi Peter, Thank you for pointing out the CSR process. I've learnt. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 17:47:41: > From: "Langer, Christoph" > To: Peter Levart , Kazunori Ogata > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, core-libs-dev , > "nio-dev at openjdk.java.net" > Date: 2017/06/28 17:47 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Petar, > > thanks for pointing out the need for the CSR, I thought so too. > > I?ll run through the CSR process? It?ll probably be an interesting > learning experience for me as well J > > Best regards > Christoph > > From: Peter Levart [mailto:peter.levart at gmail.com] > Sent: Mittwoch, 28. Juni 2017 10:45 > To: Kazunori Ogata ; Langer, Christoph > Cc: ppc-aix-port-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > The change looks good. > > But I think this needs to go through CSR. The CSR FAQ page at: > > https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > writes... > > Q: What sort of changes require CSR review? > A: Any change to a JDK interface meant to be used outside of the JDK > itself requires CSR review. In this context "interface" isn't limited to > the Java programing language definition of an interface, but encompasses > the broader concept of a protocol between the JDK and users of the JDK. > Examples of interfaces by this definition include: > > ... > Changing or defining a new system or security property > > > The FAQ also writes: > > Q: How do I create a CSR ? > A: Do not directly create a CSR from the Create Menu. JIRA will let you do > this right up until the moment you try to save it and find your typing was in vain. > Instead you should go to the target bug, select "More", and from the drop > down menu select "Create CSR". This is required to properly associate the > CSR with the main bug, just as is done for backports. > > Since Christoph has already volunteered to be your sponsor, you could ask > him to file the CSR for you. Or I can volunteer to file it (and learn how > this goes) if Christoph doesn't have the time. It's Christophs call... > > Regards, Peter > On 06/28/2017 08:20 AM, Kazunori Ogata wrote: > Hi Christoph, > > Thank you for your suggestions and offering to sponsor my changes. > > Here is the updated webrev that removes the atBugLevel() definition in > Charset.java and its call sites in Charset.java and > Charset-X-Coder.java.template. Please review this: > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 03:32:51: > > From: "Langer, Christoph" > To: Alan Bateman , Kazunori Ogata > > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Claes Redestad , core- > libs-dev , "nio-dev at openjdk.java.net" > > Date: 2017/06/28 03:32 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > I think I agree with Alan that the Charset.atBugLevel() method can > completely be eliminated from java/nio/charset. > > Ogata, would you respin your change to remove it and post it for review? > I > can then sponsor it for you. > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > here since support for "sun.nio.cs.bugLevel" will be removed? > > Best regards > Christoph > > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Dienstag, 27. Juni 2017 10:13 > To: Claes Redestad ; Langer, Christoph > ; Kazunori Ogata ; > core-libs-dev ; > nio-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 08:36, Claes Redestad wrote: > > The check of Charset.atBugLevel in checkName should no longer happen > for the majority of situations, as that test is now only done if the > charset name is "" (see > https://bugs.openjdk.java.net/browse/JDK-8174831), > Kazunori's mail didn't mention the JDK build he is using, it may have > been JDK 8 rather than JDK 9. > > since what differs between 1.4 and 1.5 was apparently whether or not > the empty string was to be accepted as a valid Charset... > > So yes, if we can get rid of the test altogether, we'll be even > better > off! > JDK-4786884 is the original issue. If there was any code dependent on > the broken behavior in 1.4 then I would expect it should have been > fixed > by now. So I think it can be removed. > > -Alan > > > From christoph.langer at sap.com Wed Jun 28 09:41:04 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 09:41:04 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <587313ab0dcf483abb3eb300bc779695@sap.com> Message-ID: Hi Claes, this looks like a good idea, too. I'll try to take care of it after the Charset.atBugLevel() is done. Best regards Christoph > -----Original Message----- > From: Claes Redestad [mailto:claes.redestad at oracle.com] > Sent: Mittwoch, 28. Juni 2017 10:58 > To: Langer, Christoph ; Kazunori Ogata > > Cc: Alan Bateman ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Looks good to me, pending CSR approval. > > Additionally, maybe this is a good opportunity to re-examine the very > similarly implemented sun.nio.ch.bugLevel used in sun.nio.ch.Util and > sun.nio.ch.SelectorImpl? > > As a separate bug, of course. > > /Claes > From OGATAK at jp.ibm.com Wed Jun 28 09:59:09 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 28 Jun 2017 18:59:09 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: Hi Christoph, Thank you for your help. I'll change the tests and update weberv. > remove the second run with -Dsun.nio.cs.bugLevel=1.4 How can I do this? Is it sufficient to remove the following line at the beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" > PS: The bug is https://bugs.openjdk.java.net/browse/JDK-8182743, not > 8179527, as the Subject indicates. Oops, I'm sorry. It was the number that my colleague opened before... Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 18:23:43: > From: "Langer, Christoph" > To: Alan Bateman , Kazunori Ogata > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, Claes Redestad , core- > libs-dev , "nio-dev at openjdk.java.net" > > Date: 2017/06/28 18:24 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi, > > I just filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8183116. I > set it to status "Proposed". I assume it will be handled by the csr group > automatically? > > As for the patch: I just recognized that we'll need to update the tests > jdk/test/java/nio/charset/Charset/EmptyCharsetName.java and jdk/test/java/ > nio/charset/CharsetDecoder/AverageMax.java if we remove > "sun.nio.cs.bugLevel". E.g. remove the second run with - > Dsun.nio.cs.bugLevel=1.4 and clean the code for that. @Ogata: Can you > please do that? You might chose to wait until the CSR process is done... > > Best regards > Christoph > > PS: The bug is https://bugs.openjdk.java.net/browse/JDK-8182743, not > 8179527, as the Subject indicates. > > > > -----Original Message----- > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > Sent: Mittwoch, 28. Juni 2017 11:00 > > To: Langer, Christoph ; Kazunori Ogata > > > > Cc: ppc-aix-port-dev at openjdk.java.net; Claes Redestad > > ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > > > > > On 27/06/2017 19:32, Langer, Christoph wrote: > > > : > > > > > > @Alan: Do we need a CSR ("Compatibility & Specification Review") request > > here since support for "sun.nio.cs.bugLevel" will be removed? > > > > > This system property pre-dates OpenJDK but it would have had a CCC at > > the time. So creating a CSR to indicate that it can no longer be used to > > get to JDK 1.4 behavior would be good. Thanks. > > > > -Alan From thomas.stuefe at gmail.com Wed Jun 28 10:22:02 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Jun 2017 12:22:02 +0200 Subject: RFR(s): [aix]: 8182984: [aix] Make stack traces independent on successful vm initialization Message-ID: Hi all, please review, at your convenience, the following AIX-only fix: Issue: https://bugs.openjdk.java.net/browse/JDK-8182984 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182984-aix- better-stacktraces/webrev.00/webrev/ In short, it improves the chances of getting better callstacks if the VM crashes or asserts before os::init() ran or if os::init() ran into an error. Details: callstack printing is implemented in our porting layer (porting_aix.hpp/cpp), in "AixNativeCallstack::print_ callstack_for_context()". This change makes this independent from VM infrastructure (it should be, because the porting layer should be below the hotspot and should not have dependencies into it). For one, it is not necessary to use Thread::current() to get the current threads stack bounds, because that requires pthread TLS being initialized successfully and a current Thread* to exist. For the purpose of stack trace printing, we can just call pthread_getthrds_np(). Then, we use os::vm_page_size() to align the lower stack boundary to the stack page size (to place our guard pages later). This is a hotspot implementation detail and does not have to be done in the porting layer, but should be moved upward to os::current_stack_size(). Thank you for reviewing, Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Jun 28 08:44:38 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Jun 2017 10:44:38 +0200 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> Message-ID: Hi Ogata, The change looks good. But I think this needs to go through CSR. The CSR FAQ page at: https://wiki.openjdk.java.net/display/csr/CSR+FAQs writes... Q: What sort of changes require CSR review? A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR review. In this context "interface" isn't limited to the Java programing language definition of an interface, but encompasses the broader concept of a protocol between the JDK and users of the JDK. Examples of interfaces by this definition include: ... * Changing or defining a new system or security property* The FAQ also writes: Q: How do I create a CSR ? A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain. Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports. Since Christoph has already volunteered to be your sponsor, you could ask him to file the CSR for you. Or I can volunteer to file it (and learn how this goes) if Christoph doesn't have the time. It's Christophs call... Regards, Peter On 06/28/2017 08:20 AM, Kazunori Ogata wrote: > Hi Christoph, > > Thank you for your suggestions and offering to sponsor my changes. > > Here is the updated webrev that removes the atBugLevel() definition in > Charset.java and its call sites in Charset.java and > Charset-X-Coder.java.template. Please review this: > > http://cr.openjdk.java.net/~horii/8179527/webrev.01/ > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 03:32:51: > >> From: "Langer, Christoph" >> To: Alan Bateman , Kazunori Ogata > >> Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, Claes Redestad , core- >> libs-dev , "nio-dev at openjdk.java.net" >> >> Date: 2017/06/28 03:32 >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >> Charset.atBugLevel() >> >> Hi Ogata, >> >> I think I agree with Alan that the Charset.atBugLevel() method can >> completely be eliminated from java/nio/charset. >> >> Ogata, would you respin your change to remove it and post it for review? > I >> can then sponsor it for you. >> >> @Alan: Do we need a CSR ("Compatibility & Specification Review") request >> here since support for "sun.nio.cs.bugLevel" will be removed? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Dienstag, 27. Juni 2017 10:13 >>> To: Claes Redestad ; Langer, Christoph >>> ; Kazunori Ogata ; >>> core-libs-dev ; > nio-dev at openjdk.java.net >>> Cc: ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: 8179527: Ineffective use of volatile hurts performance of >>> Charset.atBugLevel() >>> >>> On 27/06/2017 08:36, Claes Redestad wrote: >>>> The check of Charset.atBugLevel in checkName should no longer happen >>>> for the majority of situations, as that test is now only done if the >>>> charset name is "" (see >>>> https://bugs.openjdk.java.net/browse/JDK-8174831), >>> Kazunori's mail didn't mention the JDK build he is using, it may have >>> been JDK 8 rather than JDK 9. >>> >>>> since what differs between 1.4 and 1.5 was apparently whether or not >>>> the empty string was to be accepted as a valid Charset... >>>> >>>> So yes, if we can get rid of the test altogether, we'll be even > better >>>> off! >>> JDK-4786884 is the original issue. If there was any code dependent on >>> the broken behavior in 1.4 then I would expect it should have been > fixed >>> by now. So I think it can be removed. >>> >>> -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jun 28 12:04:36 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 28 Jun 2017 12:04:36 +0000 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> Message-ID: <254e340e1a084a57bd77c1a99884ce1b@sap.com> Hi Ogata, > > remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > How can I do this? Is it sufficient to remove the following line at the > beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > EmptyCharsetName" Yes, this line should be removed. Currently there are two @run directives which cause running the testcase twice. Once in normal mode and once with bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed then the second iteration of the test is obsolete. And then one should probably remove the whole "compat" handling in the test. Best regards Christoph From volker.simonis at gmail.com Wed Jun 28 12:34:49 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Jun 2017 14:34:49 +0200 Subject: RFR(s): [aix]: 8182984: [aix] Make stack traces independent on successful vm initialization In-Reply-To: References: Message-ID: Hi Thomas, the change looks good. Following just a little nit-picking: os_aix.cpp - you can also remove the comment "133 // Query dimensions of the stack of the calling thread." porting_aix.cpp - the comment "base, high" should be on the line: 856 // | --------------------- __pi_stackend instead of: 852 // high addr --------------------- - why do we need the field 'address high' which is merely an alias for 'base' ? I'd remove it. There's no need for a new webrev if you agree with my suggestions :) Thank you and best regards, Volker On Wed, Jun 28, 2017 at 12:22 PM, Thomas St?fe wrote: > Hi all, > > please review, at your convenience, the following AIX-only fix: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8182984 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8182984-aix-better-stacktraces/webrev.00/webrev/ > > In short, it improves the chances of getting better callstacks if the VM > crashes or asserts before os::init() ran or if os::init() ran into an error. > > Details: > > callstack printing is implemented in our porting layer > (porting_aix.hpp/cpp), in > "AixNativeCallstack::print_callstack_for_context()". > > This change makes this independent from VM infrastructure (it should be, > because the porting layer should be below the hotspot and should not have > dependencies into it). > > For one, it is not necessary to use Thread::current() to get the current > threads stack bounds, because that requires pthread TLS being initialized > successfully and a current Thread* to exist. For the purpose of stack trace > printing, we can just call pthread_getthrds_np(). > > Then, we use os::vm_page_size() to align the lower stack boundary to the > stack page size (to place our guard pages later). This is a hotspot > implementation detail and does not have to be done in the porting layer, but > should be moved upward to os::current_stack_size(). > > Thank you for reviewing, > > Kind Regards, Thomas From martin.doerr at sap.com Wed Jun 28 13:07:38 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 28 Jun 2017 13:07:38 +0000 Subject: RFR(s): [aix]: 8182984: [aix] Make stack traces independent on successful vm initialization In-Reply-To: References: Message-ID: <1c5ef594feb94542a2a1e3939ef1c3dc@sap.com> Hi Thomas, thanks for fixing this. The new code also looks much better regarding readability. I agree with Volker. I also don't like keeping the same information twice in strackbounds_t. E.g. the 2 convenience fields could be replaced by convenience functions. Thanks and best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Mittwoch, 28. Juni 2017 14:35 To: Thomas St?fe Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(s): [aix]: 8182984: [aix] Make stack traces independent on successful vm initialization Hi Thomas, the change looks good. Following just a little nit-picking: os_aix.cpp - you can also remove the comment "133 // Query dimensions of the stack of the calling thread." porting_aix.cpp - the comment "base, high" should be on the line: 856 // | --------------------- __pi_stackend instead of: 852 // high addr --------------------- - why do we need the field 'address high' which is merely an alias for 'base' ? I'd remove it. There's no need for a new webrev if you agree with my suggestions :) Thank you and best regards, Volker On Wed, Jun 28, 2017 at 12:22 PM, Thomas St?fe wrote: > Hi all, > > please review, at your convenience, the following AIX-only fix: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8182984 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8182984-aix-better-stacktraces/webrev.00/webrev/ > > In short, it improves the chances of getting better callstacks if the VM > crashes or asserts before os::init() ran or if os::init() ran into an error. > > Details: > > callstack printing is implemented in our porting layer > (porting_aix.hpp/cpp), in > "AixNativeCallstack::print_callstack_for_context()". > > This change makes this independent from VM infrastructure (it should be, > because the porting layer should be below the hotspot and should not have > dependencies into it). > > For one, it is not necessary to use Thread::current() to get the current > threads stack bounds, because that requires pthread TLS being initialized > successfully and a current Thread* to exist. For the purpose of stack trace > printing, we can just call pthread_getthrds_np(). > > Then, we use os::vm_page_size() to align the lower stack boundary to the > stack page size (to place our guard pages later). This is a hotspot > implementation detail and does not have to be done in the porting layer, but > should be moved upward to os::current_stack_size(). > > Thank you for reviewing, > > Kind Regards, Thomas From thomas.stuefe at gmail.com Wed Jun 28 13:42:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 28 Jun 2017 15:42:03 +0200 Subject: RFR(s): [aix]: 8182984: [aix] Make stack traces independent on successful vm initialization In-Reply-To: References: Message-ID: Thank you Volker! I agree with yours (and Martins) suggestions - will remove the superfluous struct member. Christoph also had a suggestion offlist to add error handling in porting_aix.cpp for the case that we cannot retrieve the callstack. I will add that too. Kind Regards, Thomas On Wed, Jun 28, 2017 at 2:34 PM, Volker Simonis wrote: > Hi Thomas, > > the change looks good. Following just a little nit-picking: > > os_aix.cpp > - you can also remove the comment "133 // Query dimensions of the > stack of the calling thread." > > porting_aix.cpp > - the comment "base, high" should be on the line: > 856 // | --------------------- __pi_stackend > instead of: > 852 // high addr --------------------- > > - why do we need the field 'address high' which is merely an alias for > 'base' ? I'd remove it. > > There's no need for a new webrev if you agree with my suggestions :) > > Thank you and best regards, > Volker > > > On Wed, Jun 28, 2017 at 12:22 PM, Thomas St?fe > wrote: > > Hi all, > > > > please review, at your convenience, the following AIX-only fix: > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8182984 > > Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8182984-aix- > better-stacktraces/webrev.00/webrev/ > > > > In short, it improves the chances of getting better callstacks if the VM > > crashes or asserts before os::init() ran or if os::init() ran into an > error. > > > > Details: > > > > callstack printing is implemented in our porting layer > > (porting_aix.hpp/cpp), in > > "AixNativeCallstack::print_callstack_for_context()". > > > > This change makes this independent from VM infrastructure (it should be, > > because the porting layer should be below the hotspot and should not have > > dependencies into it). > > > > For one, it is not necessary to use Thread::current() to get the current > > threads stack bounds, because that requires pthread TLS being initialized > > successfully and a current Thread* to exist. For the purpose of stack > trace > > printing, we can just call pthread_getthrds_np(). > > > > Then, we use os::vm_page_size() to align the lower stack boundary to the > > stack page size (to place our guard pages later). This is a hotspot > > implementation detail and does not have to be done in the porting layer, > but > > should be moved upward to os::current_stack_size(). > > > > Thank you for reviewing, > > > > Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbrandy at linux.vnet.ibm.com Thu Jun 29 13:37:07 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Thu, 29 Jun 2017 08:37:07 -0500 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <95d5cb36271e4ebf8398223702b61ac8@sap.com> References: <8b53b855-f540-bb89-dcbb-bf0f5bb35b17@linux.vnet.ibm.com> <2a4fcb315f4d44199e8cc66935886f41@sap.com> <651ebdd4-3854-ac42-8e9c-54df77cbb5fc@linux.vnet.ibm.com> <56073cca-0c7a-0436-4e95-6d74a1bbe404@linux.vnet.ibm.com> <20c43bf4-a66b-2cc8-e62f-d58eb66df278@linux.vnet.ibm.com> <0f82ddbcf57348e8ac6e6cd9e51674f3@sap.com> <95d5cb36271e4ebf8398223702b61ac8@sap.com> Message-ID: <232e0b79-9022-bf4b-4c40-88880c68d22e@linux.vnet.ibm.com> Thanks Martin. That looks good. Is there anything I need to do to request a 2nd review? On 6/26/17 7:47 AM, Doerr, Martin wrote: > Hi Matt, > > after some testing and reviewing the C1 part again, I found 2 bugs: > > c1_LIRAssembler: is_stack() can't be used for this purpose as the value may be available in a register even though it was forced to stack. I just changed src_in_memory = !VM_Version::has_mtfprd() to make it consistent with LIRGenerator and removed the assertions which have become redundant. > > c1_LIRGenerator: value.set_destroys_register() is still needed for conversion from FP to GP registers because they kill the src value by fctiwz/fctidz. > > I just fixed these issues here in a copy of your webrev v2: > http://cr.openjdk.java.net/~mdoerr/8181809_ppc64_mtfprd/v2/ > > Please take a look and use this one for 2nd review. > > Best regards, > Martin > > > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 26. Juni 2017 10:44 > To: 'Matthew Brandyberry' ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RE: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 > > Hi Matt, > > you can run the pre-push check stand-alone: hg jcheck > See: > http://openjdk.java.net/projects/code-tools/jcheck/ > > I just had to add the commit message: > 8181809: PPC64: Leverage mtfprd/mffprd on POWER8 > Reviewed-by: mdoerr > Contributed-by: Matthew Brandyberry > > (Note that the ':' after the bug id is important.) > > and replace the Tabs the 2 C1 files to get it passing. > (I think that "Illegal tag name" warnings can be ignored.) > > So only the copyright dates are missing which are not checked by jcheck. > But I don't need a new webrev if that's all which needs to be changed. > > Best regards, > Martin > > > -----Original Message----- > From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] > Sent: Freitag, 23. Juni 2017 18:39 > To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 > > Thanks Martin. Are there tools to help detect formatting errors like the > tab characters? > > I'll keep an eye on this to see if I need to do anything else. > > -Matt > > On 6/23/17 4:30 AM, Doerr, Martin wrote: >> Excellent. Thanks for the update. The C1 part looks good, too. >> >> Also, thanks for checking "I could not find evidence of any config that includes vpmsumb but not >> mtfprd." >> >> There are only a few formally required things: >> - The new C1 code contains Tab characters. It's not possible to push it without fixing this. >> - Copyright messages should be updated. >> - Minor resolution to get vm_version_ppc applied to recent jdk10/hs. >> >> If no other changes get requested, I can handle these issues this time before pushing. >> But we need another review, first. >> >> Thanks and best regards, >> Martin >> >> >> -----Original Message----- >> From: Matthew Brandyberry [mailto:mbrandy at linux.vnet.ibm.com] >> Sent: Freitag, 23. Juni 2017 04:54 >> To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >> >> Updated webrev: http://cr.openjdk.java.net/~gromero/8181809/v2/ >> >> See below for responses inline. >> >> On 6/20/17 8:38 AM, Matthew Brandyberry wrote: >>> Hi Martin, >>> >>> Thanks for the review. I'll take a look at these areas and report >>> back -- especially the integration into C1. >>> >>> On 6/20/17 8:33 AM, Doerr, Martin wrote: >>>> Hi Matt, >>>> >>>> thanks for providing this webrev. I had already thought about using >>>> these instructions for this purpose and your change matches pretty >>>> much what I'd do. >>>> >>>> Here a couple of comments: >>>> ppc.ad: >>>> This was a lot of work. Thanks for doing it. >>>> effect(DEF dst, USE src); is redundant if a match rule match(Set dst >>>> (MoveL2D src)); exists. >> Fixed. >>>> vm_version: >>>> This part is in conflict with Michihiro's change which is already >>>> pushed in jdk10, but it's trivial to resolve. I'm ok with using >>>> has_vpmsumb() for has_mtfprd(). In the past, we sometimes had trouble >>>> with assuming that a certain Power processor supports all new >>>> instructions if it supports certain ones. We also use the hotspot >>>> code on as400 where certain instruction subsets were disabled while >>>> other Power 8 instructions were usable. Maybe you can double-check if >>>> there may exist configurations in which has_vpmsumb() doesn't match >>>> has_mtfprd(). >> I could not find evidence of any config that includes vpmsumb but not >> mtfprd. >>>> C1: >>>> It should also be possible to use the instructions in C1 compiler. >>>> Maybe you would like to take a look at it as well and see if it can >>>> be done with feasible effort. >>>> Here are some hints: >>>> The basic decisions are made in LIRGenerator::do_Convert. You could >>>> skip the force_to_spill or must_start_in_memory steps. >>>> The final assembly code gets emitted in LIR_Assembler::emit_opConvert >>>> where you could replace the store instructions. >>>> For testing, you can use -XX:TieredStopAtLevel=1, for example. >> Done. Please take a look. >>>> Thanks and best regards, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Matthew Brandyberry >>>> Sent: Montag, 19. Juni 2017 18:28 >>>> To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>>> Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 >>>> >>>> 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. Please review: Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8181809 Webrev: >>>> http://cr.openjdk.java.net/~gromero/8181809/v1/ Thanks, Matt >>>> >>>> From OGATAK at jp.ibm.com Thu Jun 29 18:49:18 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 30 Jun 2017 03:49:18 +0900 Subject: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <254e340e1a084a57bd77c1a99884ce1b@sap.com> References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi Christoph, I updated webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.02/ This one includes changes in tests. I removed all @run and @build directives in the tests because those after removing "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the default ones. I checked the modified tests passed. I also fixed the copyright lines. Regards, Ogata "Langer, Christoph" wrote on 2017/06/28 21:04:36: > From: "Langer, Christoph" > To: Kazunori Ogata > Cc: Alan Bateman , Claes Redestad > , core-libs-dev dev at openjdk.java.net>, "nio-dev at openjdk.java.net" dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net> > Date: 2017/06/28 21:04 > Subject: RE: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > > > remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > > > How can I do this? Is it sufficient to remove the following line at the > > beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > > EmptyCharsetName" > > Yes, this line should be removed. Currently there are two @run directives > which cause running the testcase twice. Once in normal mode and once with > bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed then > the second iteration of the test is obsolete. And then one should probably > remove the whole "compat" handling in the test. > > Best regards > Christoph > From jrheath at ca.ibm.com Thu Jun 29 21:17:20 2017 From: jrheath at ca.ibm.com (Jeff Heath) Date: Thu, 29 Jun 2017 17:17:20 -0400 Subject: Fw: C++11/C++14 support in XLC ? In-Reply-To: References: Message-ID: Hi all, On the LE Linux platform, XL C/C++ V13.1.5 has full support of C++11 and partial support of C++14. On AIX, XL C/C++ V13.1.3 has partial support of C++11. The exact feature list is described in the language reference, but is available in a more consumable form here [1]. This is still a pretty current list. [1] https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/What_new_C_11_language_features_you_will_get_by_using_the_latest_XL_C_C_V13_1_2_and_a_sneak_peak_at_C_14?lang=en Regards, Jeff -------- Forwarded Message -------- Subject: C++11/C++14 support in XLC ? Date: Fri, 23 Jun 2017 09:14:09 +0200 From: Volker Simonis To: ppc-aix-port-dev at openjdk.java.net CC: Kim Barrett Hi everybody, Kim recently approached me with some questions regarding the amount and quality of C++11/C++14 support in XLC (see his mail below). As he found out, it seems that there's unfortunately not much of even C++11 support in recent XLC compilers [1,2]. I think, one of the features most badly needed is the support for atomics operations library [3] which was introduced with C++11. A recent hotspot mail thread [4,5] may give an impression why the atomics library is need (but obviously only makes sense if it is high-quality, bullet-proof on all supported platforms) I would be great if somebody from the IBM folks on this list could provide some more detailed information on the current state of the C++11/C++14/C++XX support in XLC and the future plans if possible. Thank you and best regards, Volker ---------- Forwarded message ---------- From: Kim Barrett Date: Wed, Jun 21, 2017 at 6:23 AM Subject: c++11 ? To: Volker Simonis Hi Volker, There's been a lot of internal discussion here at Oracle about possibly updating compilers and starting to use C++11 or even C++14 features, for JDK10 or beyond. Until recently I thought C++11 was practical, just a matter of doing the work. This was based in part on information I'd seen about XLC++ supporting C++11. However, I recently found documentation [1] [2] indicating that's only true for the Linux port, and that even the latest version of the AIX port is seriously laggard, only providing a few specific C++11 features. If that's accurate, that's very disappointing. I was wondering if you or your group might have any additional information or thoughts? [1] https://www-03.ibm.com/software/products/en/xlcpp-aix [2] https://www-01.ibm.com/support/docview.wss?uid=swg27047114 [3] http://en.cppreference.com/w/cpp/atomic [4] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-May/thread.html#224 [5] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/thread.html#268 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.reix at atos.net Fri Jun 30 07:29:43 2017 From: tony.reix at atos.net (REIX, Tony) Date: Fri, 30 Jun 2017 07:29:43 +0000 Subject: OpenJDK on BullFreeware Message-ID: Hi, I am one of the maintainers of the BullFreeware web-site where RPMs of OpenSource packages for AIX are available (for free): http://www.bullfreeware.com . I'd like to know: - what is the status of this port of OpenJDK on AIX (is it usable in production ?), - where are the sources and the instructions for building it, and - if there already exists a RPM .spec file for building RPMs. Thanks/Regards, Cordialement, Tony Reix Bull - ATOS IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 ?chirolles - France www.atos.net From sean.coffey at oracle.com Fri Jun 30 14:57:25 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 30 Jun 2017 15:57:25 +0100 Subject: 8179527:(8182743?) Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Ogata, minor comments from me. * The bug ID referenced in mail/webrev links is wrong. It should be 8182743 ? * The copyright change in Charset-X-Coder.java.template is the wrong format. You can simply replace 2013 with 2017. Regards, Sean. On 29/06/17 19:49, Kazunori Ogata wrote: > Hi Christoph, > > I updated webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > This one includes changes in tests. I removed all @run and @build > directives in the tests because those after removing "@run main/othervm > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the default > ones. I checked the modified tests passed. > > I also fixed the copyright lines. > > > Regards, > Ogata > > > "Langer, Christoph" wrote on 2017/06/28 > 21:04:36: > >> From: "Langer, Christoph" >> To: Kazunori Ogata >> Cc: Alan Bateman , Claes Redestad >> , core-libs-dev > dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > dev at openjdk.java.net> >> Date: 2017/06/28 21:04 >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of >> Charset.atBugLevel() >> >> Hi Ogata, >> >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 >>> How can I do this? Is it sufficient to remove the following line at > the >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 >>> EmptyCharsetName" >> Yes, this line should be removed. Currently there are two @run > directives >> which cause running the testcase twice. Once in normal mode and once > with >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > then >> the second iteration of the test is obsolete. And then one should > probably >> remove the whole "compat" handling in the test. >> >> Best regards >> Christoph >> > From volker.simonis at gmail.com Fri Jun 30 15:58:52 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 Jun 2017 17:58:52 +0200 Subject: Fw: C++11/C++14 support in XLC ? In-Reply-To: References: Message-ID: Hi Jeff, thanks a lot for providing the new link. As mentioned earlier in this thread, one of the main interests of the OpenJDK project in the C++11 features is for the new atomic/concurrency features. Unfortunately, as per your list, they don't seem to be supported at all on AIX and there's also no information on when they will be supported (if at all). It would be great if you could keep us posted once new features will become available. Regards, Volker On Thu, Jun 29, 2017 at 11:17 PM, Jeff Heath wrote: > Hi all, > > On the LE Linux platform, XL C/C++ V13.1.5 has full support of C++11 and > partial support of C++14. On AIX, XL C/C++ V13.1.3 has partial support of > C++11. The exact feature list is described in the language reference, but > is available in a more consumable form here [1]. This is still a pretty > current list. > > [1] > https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/What_new_C_11_language_features_you_will_get_by_using_the_latest_XL_C_C_V13_1_2_and_a_sneak_peak_at_C_14?lang=en > > Regards, > > Jeff > > > -------- Forwarded Message -------- > Subject: C++11/C++14 support in XLC ? > Date: Fri, 23 Jun 2017 09:14:09 +0200 > From: Volker Simonis > To: ppc-aix-port-dev at openjdk.java.net > CC: Kim Barrett > > Hi everybody, > > Kim recently approached me with some questions regarding the amount > and quality of C++11/C++14 support in XLC (see his mail below). As he > found out, it seems that there's unfortunately not much of even C++11 > support in recent XLC compilers [1,2]. > > I think, one of the features most badly needed is the support for > atomics operations library [3] which was introduced with C++11. A > recent hotspot mail thread [4,5] may give an impression why the > atomics library is need (but obviously only makes sense if it is > high-quality, bullet-proof on all supported platforms) > > I would be great if somebody from the IBM folks on this list could > provide some more detailed information on the current state of the > C++11/C++14/C++XX support in XLC and the future plans if possible. > > Thank you and best regards, > Volker > > > ---------- Forwarded message ---------- > From: Kim Barrett > Date: Wed, Jun 21, 2017 at 6:23 AM > Subject: c++11 ? > To: Volker Simonis > > Hi Volker, > > There's been a lot of internal discussion here at Oracle about > possibly updating compilers and starting to use C++11 or even C++14 > features, for JDK10 or beyond. Until recently I thought C++11 was > practical, just a matter of doing the work. This was based in part on > information I'd seen about XLC++ supporting C++11. However, I > recently found documentation [1] [2] indicating that's only true for > the Linux port, and that even the latest version of the AIX port is > seriously laggard, only providing a few specific C++11 features. If > that's accurate, that's very disappointing. I was wondering if you or > your group might have any additional information or thoughts? > > [1] https://www-03.ibm.com/software/products/en/xlcpp-aix > [2] https://www-01.ibm.com/support/docview.wss?uid=swg27047114 > [3] http://en.cppreference.com/w/cpp/atomic > [4] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-May/thread.html#224 > [5] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/thread.html#268 > From volker.simonis at gmail.com Fri Jun 30 16:23:55 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 Jun 2017 18:23:55 +0200 Subject: OpenJDK on BullFreeware In-Reply-To: References: Message-ID: Hi Tony, thanks for your interest in the OpenJDK AIX port. The AIX port has been contributed by SAP in collaboration with our colleagues from IBM. It is based on SAP's internal, commercially licensed SAP JVM which is in productive use since more than 10 years. We (from SAP) do nightly builds and tests of the OpenJDK AIX port and we're happy to help with any issues we see or which are reported by the community. But of course we can not guarantee any support - after all it's an open source project :) We've also contributed the OpenJDK linux/ppc64 port which is basically the same as the AIX port with regard to the CPU-specific code (i.e. interpreter, JIT, shared code, etc) and only differs in the OS-specific part (i.e. Linux vs. AIX). We know that the linux/ppc64 port is currently distributed by all major Linux vendors (RedHat, Ubuntu, Suse, etc) and used productively on their distributions without any major issues. Until now there hasn't been such a big interest in the AIX port (for obvious reasons :) but we would very much welcome a more widespread usage. Unfortunately, there's not much AIX-specific information available. You can get the basic bits from our project page [1] and Wiki [2]. The repositories for AIX are the current OpenJDK master repositories for jdk8u [3] and jdk9 [4]. Recently, IBM has started an effort together with the AdoptOpenJDK [5] project to establish a regular, open and freely available OpenJDK build and deliver the produced binaries. I've just invited you to their Slack channel (you should receive it by mail). Please follow that thread where we've recently discussed some build issues. One thing that may be of special interest for you is the the build currently only works with XLC and relies on some libraries from the "AIX toolbox for Linux" from IBM (i.e. for freetype). Also, we don't have RPM .spec files for building RPM until now. If you have any more questions please feel free to ask on this list and/or the Slack channel. Regards, Volker [1] http://openjdk.java.net/projects/ppc-aix-port/ [2] https://wiki.openjdk.java.net/display/PPCAIXPort [3] http://hg.openjdk.java.net/jdk8u [4] http://hg.openjdk.java.net/jdk9 [5] https://wiki.openjdk.java.net/display/Adoption/Main On Fri, Jun 30, 2017 at 9:29 AM, REIX, Tony wrote: > Hi, > > I am one of the maintainers of the BullFreeware web-site where RPMs of OpenSource packages for AIX are available (for free): http://www.bullfreeware.com . > > I'd like to know: > - what is the status of this port of OpenJDK on AIX (is it usable in production ?), > - where are the sources and the instructions for building it, and > - if there already exists a RPM .spec file for building RPMs. > > Thanks/Regards, > > Cordialement, > > Tony Reix > > Bull - ATOS > IBM Coop Architect & Technical Leader > Office : +33 (0) 4 76 29 72 67 > 1 rue de Provence - 38432 ?chirolles - France > www.atos.net From OGATAK at jp.ibm.com Fri Jun 30 18:30:49 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Sat, 1 Jul 2017 03:30:49 +0900 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi Sean, Thank you for your comments. I fixed the copyright and updated webrev: http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > * The bug ID referenced in mail/webrev links is wrong. It should be > 8182743 ? Yes, they should be 8182743. I fixed both. Regards, Ogata Se?n Coffey wrote on 2017/06/30 23:57:25: > From: Se?n Coffey > To: Kazunori Ogata , "Langer, Christoph" > > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, core-libs-dev , > "nio-dev at openjdk.java.net" > Date: 2017/06/30 23:57 > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > performance of Charset.atBugLevel() > > Ogata, > > minor comments from me. > > * The bug ID referenced in mail/webrev links is wrong. It should be > 8182743 ? > * The copyright change in Charset-X-Coder.java.template is the wrong > format. You can simply replace 2013 with 2017. > > Regards, > Sean. > > On 29/06/17 19:49, Kazunori Ogata wrote: > > Hi Christoph, > > > > I updated webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > This one includes changes in tests. I removed all @run and @build > > directives in the tests because those after removing "@run main/othervm > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the default > > ones. I checked the modified tests passed. > > > > I also fixed the copyright lines. > > > > > > Regards, > > Ogata > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > 21:04:36: > > > >> From: "Langer, Christoph" > >> To: Kazunori Ogata > >> Cc: Alan Bateman , Claes Redestad > >> , core-libs-dev >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > >> dev at openjdk.java.net> > >> Date: 2017/06/28 21:04 > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance of > >> Charset.atBugLevel() > >> > >> Hi Ogata, > >> > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > >>> How can I do this? Is it sufficient to remove the following line at > > the > >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > >>> EmptyCharsetName" > >> Yes, this line should be removed. Currently there are two @run > > directives > >> which cause running the testcase twice. Once in normal mode and once > > with > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > > then > >> the second iteration of the test is obsolete. And then one should > > probably > >> remove the whole "compat" handling in the test. > >> > >> Best regards > >> Christoph > >> > > > From kim.barrett at oracle.com Fri Jun 30 22:08:06 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 30 Jun 2017 18:08:06 -0400 Subject: C++11/C++14 support in XLC ? In-Reply-To: References: Message-ID: <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com> > On Jun 29, 2017, at 5:17 PM, Jeff Heath wrote: > > Hi all, > > On the LE Linux platform, XL C/C++ V13.1.5 has full support of C++11 and partial support of C++14. On AIX, XL C/C++ V13.1.3 has partial support of C++11. The exact feature list is described in the language reference, but is available in a more consumable form here [1]. This is still a pretty current list. > > [1] https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/What_new_C_11_language_features_you_will_get_by_using_the_latest_XL_C_C_V13_1_2_and_a_sneak_peak_at_C_14?lang=en > > Regards, > > Jeff Thanks for the link. Besides atomics/concurrency that Volker mentioned, some other features that I recall coming up include constexpr support (especially C++14 more relaxed constexpr) and type traits and related metaprogramming tools. And in a recent discussion of bugs arising from seconds vs milliseconds mismatches, some folks were looking wistfully at std::chrono. However, just the sheer number of holes in the AIX column is a significant concern. Here at Oracle, where we don't directly support the AIX port for OpenJDK, it would be all too easy for us to do some work that relies on some set of new language features, test, review, and commit it, and only later find out it all needed to be backed out and re-thought due to limitations of XLC++ on AIX. If I'm reading that table correctly, AIX has the original rvalue reference semantics? I was involved in a C++98 to C++11 conversion effort at a previous job. After some painful bugs in our code, we decided we weren't willing to use rvalue references under the original draft semantics and would only use gcc versions providing the new improved sematics, as the original was too much like running with scissors.