From OGATAK at jp.ibm.com Mon Jul 3 08:32:21 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 3 Jul 2017 17:32:21 +0900 Subject: Fw: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() Message-ID: Hi, The fix is pushed to JDK10. Started discussion on downporting the removal of volatile to JDK9u and JDK8u. Regards, Ogata ----- Forwarded by Kazunori Ogata/Japan/IBM on 2017/07/03 17:29 ----- From: "Langer, Christoph" To: Kazunori Ogata , "nio-dev at openjdk.java.net" Cc: core-libs-dev Date: 2017/07/03 17:17 Subject: RE: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() Hi, I've pushed to JDK10 now: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7a2bc0a80087 What do you think, shall we try to downport a fix to JDK9 updates and JDK8 updates, which simply removes the volatile as we can't bring this behavior changing fix down? Thanks Christoph > -----Original Message----- > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > Sent: Freitag, 30. Juni 2017 20:31 > To: Se?n Coffey > Cc: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > 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 volker.simonis at gmail.com Tue Jul 4 13:19:57 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Jul 2017 15:19:57 +0200 Subject: RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8 In-Reply-To: <232e0b79-9022-bf4b-4c40-88880c68d22e@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> <0f82ddbcf57348e8ac6e6cd9e51674f3@sap.com> <95d5cb36271e4ebf8398223702b61ac8@sap.com> <232e0b79-9022-bf4b-4c40-88880c68d22e@linux.vnet.ibm.com> Message-ID: Hi Matthew, Martin, thanks a lot for doing/reviewing this change! It looks good. Thumbs up from my side. Regards, Volker On Thu, Jun 29, 2017 at 3:37 PM, Matthew Brandyberry wrote: > 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 thomas.stuefe at gmail.com Mon Jul 17 10:55:27 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 17 Jul 2017 12:55:27 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug Message-ID: Hi all, may I please have a review for the following fix: webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet which change caused that - I suspect one of the recent template-metaprogramming changes but have not investigated yet. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Jul 17 13:19:08 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 Jul 2017 13:19:08 +0000 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: Message-ID: <7b309c4ccbef441084cf327f37e40947@sap.com> Hi Thomas, the fix looks ok to me. I?m copying build-dev because of the changes in generated-configure.sh. Don?t know if this can just be pushed from extern or if it needs some special handling from Oracle folks or other things to take care of? 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, 17. Juli 2017 12:55 To: ppc-aix-port-dev at openjdk.java.net Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug Hi all, may I please have a review for the following fix: webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet which change caused that - I suspect one of the recent template-metaprogramming changes but have not investigated yet. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Jul 17 13:29:53 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 17 Jul 2017 15:29:53 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: <7b309c4ccbef441084cf327f37e40947@sap.com> References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: Thank you Christoph! On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph wrote: > Hi Thomas, > > > > the fix looks ok to me. > > > > I?m copying build-dev because of the changes in generated-configure.sh. > Don?t know if this can just be pushed from extern or if it needs some > special handling from Oracle folks or other things to take care of? > > > > 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, 17. Juli 2017 12:55 > *To:* ppc-aix-port-dev at openjdk.java.net > *Subject:* RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug > > > > Hi all, > > > > may I please have a review for the following fix: > > > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC- > overflow/webrev.00/webrev/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 > > > > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet > which change caused that - I suspect one of the recent > template-metaprogramming changes but have not investigated yet. > > > > Thanks, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.bell at oracle.com Mon Jul 17 14:34:03 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 17 Jul 2017 07:34:03 -0700 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: <596CCADB.2000705@oracle.com> Thomas, Christoph >> I?m copying build-dev because of the changes in generated-configure.sh. >> Don?t know if this can just be pushed from extern or if it needs some >> special handling from Oracle folks or other things to take care of? Thanks for the heads up. I asked the current gatekeeper for jdk10/hs to sponsor this. You should be hearing from Dan soon. Tim >> >> >> >> 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, 17. Juli 2017 12:55 >> *To:* ppc-aix-port-dev at openjdk.java.net >> *Subject:* RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug >> >> >> >> Hi all, >> >> >> >> may I please have a review for the following fix: >> >> >> >> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC- >> overflow/webrev.00/webrev/ >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 >> >> >> >> Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet >> which change caused that - I suspect one of the recent >> template-metaprogramming changes but have not investigated yet. >> >> >> >> Thanks, Thomas >> >> >> From volker.simonis at gmail.com Mon Jul 17 15:46:32 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Jul 2017 17:46:32 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: <7b309c4ccbef441084cf327f37e40947@sap.com> References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: Hi Thomas, the change looks good, but I'd prefer if you leave the initial comment in place which also mentions "-qminimaltoc" as a way of resolving TOC overflow errors. I actually don't remember exactly, but I think "-qminimaltoc" works by creating distinct TOCs for each compilation unit. That comes with an performance impact, but "-qpic=large" / "-bbigtoc" can have an performance impact as well. As I said, for the slowdebug build your changes are fine. I'd just like to keep the reference to "-qminimaltoc" for the case where we have to re-evaluate the different solutions for the product build. Thank you and best regards, Volker On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph wrote: > Hi Thomas, > > the fix looks ok to me. > > I?m copying build-dev because of the changes in generated-configure.sh. Don?t know if this can just be pushed from extern or if it needs some special handling from Oracle folks or other things to take care of? > > 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, 17. Juli 2017 12:55 > To: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug > > Hi all, > > may I please have a review for the following fix: > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 > > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet which change caused that - I suspect one of the recent template-metaprogramming changes but have not investigated yet. > > Thanks, Thomas > From thomas.stuefe at gmail.com Tue Jul 18 05:46:48 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Jul 2017 07:46:48 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: Thank you Volker! I'll restore the original comment and prepare a new webrev. ..Thomas On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis wrote: > Hi Thomas, > > the change looks good, but I'd prefer if you leave the initial comment > in place which also mentions "-qminimaltoc" as a way of resolving TOC > overflow errors. > > I actually don't remember exactly, but I think "-qminimaltoc" works by > creating distinct TOCs for each compilation unit. That comes with an > performance impact, but "-qpic=large" / "-bbigtoc" can have an > performance impact as well. > > As I said, for the slowdebug build your changes are fine. I'd just > like to keep the reference to "-qminimaltoc" for the case where we > have to re-evaluate the different solutions for the product build. > > Thank you and best regards, > Volker > > > On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph > wrote: > > Hi Thomas, > > > > the fix looks ok to me. > > > > I?m copying build-dev because of the changes in generated-configure.sh. > Don?t know if this can just be pushed from extern or if it needs some > special handling from Oracle folks or other things to take care of? > > > > 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, 17. Juli 2017 12:55 > > To: ppc-aix-port-dev at openjdk.java.net > > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug > > > > Hi all, > > > > may I please have a review for the following fix: > > > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC- > overflow/webrev.00/webrev/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 > > > > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure > yet which change caused that - I suspect one of the recent > template-metaprogramming changes but have not investigated yet. > > > > Thanks, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue Jul 18 06:30:10 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Jul 2017 08:30:10 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: Hi Volker, new webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/ Only change is the comment, as you suggested. Kind Regards, Thomas On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe wrote: > Thank you Volker! > > I'll restore the original comment and prepare a new webrev. > > ..Thomas > > On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis > wrote: > >> Hi Thomas, >> >> the change looks good, but I'd prefer if you leave the initial comment >> in place which also mentions "-qminimaltoc" as a way of resolving TOC >> overflow errors. >> >> I actually don't remember exactly, but I think "-qminimaltoc" works by >> creating distinct TOCs for each compilation unit. That comes with an >> performance impact, but "-qpic=large" / "-bbigtoc" can have an >> performance impact as well. >> >> As I said, for the slowdebug build your changes are fine. I'd just >> like to keep the reference to "-qminimaltoc" for the case where we >> have to re-evaluate the different solutions for the product build. >> >> Thank you and best regards, >> Volker >> >> >> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph >> wrote: >> > Hi Thomas, >> > >> > the fix looks ok to me. >> > >> > I?m copying build-dev because of the changes in generated-configure.sh. >> Don?t know if this can just be pushed from extern or if it needs some >> special handling from Oracle folks or other things to take care of? >> > >> > Best regards >> > Christoph >> > >> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounc >> es at openjdk.java.net] On Behalf Of Thomas St?fe >> > Sent: Montag, 17. Juli 2017 12:55 >> > To: ppc-aix-port-dev at openjdk.java.net >> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug >> > >> > Hi all, >> > >> > may I please have a review for the following fix: >> > >> > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overf >> low/webrev.00/webrev/ >> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 >> > >> > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure >> yet which change caused that - I suspect one of the recent >> template-metaprogramming changes but have not investigated yet. >> > >> > Thanks, Thomas >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jul 18 06:58:06 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Jul 2017 08:58:06 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: Looks good! Thanks, Volker On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe wrote: > Hi Volker, > > new webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/ > > Only change is the comment, as you suggested. > > Kind Regards, Thomas > > On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe > wrote: >> >> Thank you Volker! >> >> I'll restore the original comment and prepare a new webrev. >> >> ..Thomas >> >> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis >> wrote: >>> >>> Hi Thomas, >>> >>> the change looks good, but I'd prefer if you leave the initial comment >>> in place which also mentions "-qminimaltoc" as a way of resolving TOC >>> overflow errors. >>> >>> I actually don't remember exactly, but I think "-qminimaltoc" works by >>> creating distinct TOCs for each compilation unit. That comes with an >>> performance impact, but "-qpic=large" / "-bbigtoc" can have an >>> performance impact as well. >>> >>> As I said, for the slowdebug build your changes are fine. I'd just >>> like to keep the reference to "-qminimaltoc" for the case where we >>> have to re-evaluate the different solutions for the product build. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph >>> wrote: >>> > Hi Thomas, >>> > >>> > the fix looks ok to me. >>> > >>> > I?m copying build-dev because of the changes in generated-configure.sh. >>> > Don?t know if this can just be pushed from extern or if it needs some >>> > special handling from Oracle folks or other things to take care of? >>> > >>> > 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, 17. Juli 2017 12:55 >>> > To: ppc-aix-port-dev at openjdk.java.net >>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug >>> > >>> > Hi all, >>> > >>> > may I please have a review for the following fix: >>> > >>> > webrev: >>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/ >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 >>> > >>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure >>> > yet which change caused that - I suspect one of the recent >>> > template-metaprogramming changes but have not investigated yet. >>> > >>> > Thanks, Thomas >>> > >> >> > From thomas.stuefe at gmail.com Tue Jul 18 07:18:39 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Jul 2017 09:18:39 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: Danke Volker! ... So, do I need a sponsor for this or can I push this on my own? Thanks, Thomas On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis wrote: > Looks good! > > Thanks, > Volker > > On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe > wrote: > > Hi Volker, > > > > new webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC- > overflow/webrev.01/webrev/ > > > > Only change is the comment, as you suggested. > > > > Kind Regards, Thomas > > > > On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe > > wrote: > >> > >> Thank you Volker! > >> > >> I'll restore the original comment and prepare a new webrev. > >> > >> ..Thomas > >> > >> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis < > volker.simonis at gmail.com> > >> wrote: > >>> > >>> Hi Thomas, > >>> > >>> the change looks good, but I'd prefer if you leave the initial comment > >>> in place which also mentions "-qminimaltoc" as a way of resolving TOC > >>> overflow errors. > >>> > >>> I actually don't remember exactly, but I think "-qminimaltoc" works by > >>> creating distinct TOCs for each compilation unit. That comes with an > >>> performance impact, but "-qpic=large" / "-bbigtoc" can have an > >>> performance impact as well. > >>> > >>> As I said, for the slowdebug build your changes are fine. I'd just > >>> like to keep the reference to "-qminimaltoc" for the case where we > >>> have to re-evaluate the different solutions for the product build. > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >>> > >>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph > >>> wrote: > >>> > Hi Thomas, > >>> > > >>> > the fix looks ok to me. > >>> > > >>> > I?m copying build-dev because of the changes in > generated-configure.sh. > >>> > Don?t know if this can just be pushed from extern or if it needs some > >>> > special handling from Oracle folks or other things to take care of? > >>> > > >>> > 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, 17. Juli 2017 12:55 > >>> > To: ppc-aix-port-dev at openjdk.java.net > >>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug > >>> > > >>> > Hi all, > >>> > > >>> > may I please have a review for the following fix: > >>> > > >>> > webrev: > >>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC- > overflow/webrev.00/webrev/ > >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 > >>> > > >>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not > sure > >>> > yet which change caused that - I suspect one of the recent > >>> > template-metaprogramming changes but have not investigated yet. > >>> > > >>> > Thanks, Thomas > >>> > > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jul 18 08:58:20 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Jul 2017 10:58:20 +0200 Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug In-Reply-To: References: <7b309c4ccbef441084cf327f37e40947@sap.com> Message-ID: You need a sponsor from Oracle because of the generated configure file which also needs to be generated for the Oracle closed parts. Can somebody from the build folks please push this? Thanks, Volker On Tue, Jul 18, 2017 at 9:18 AM, Thomas St?fe wrote: > Danke Volker! > > ... > > So, do I need a sponsor for this or can I push this on my own? > > Thanks, Thomas > > On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis > wrote: >> >> Looks good! >> >> Thanks, >> Volker >> >> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe >> wrote: >> > Hi Volker, >> > >> > new webrev: >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/ >> > >> > Only change is the comment, as you suggested. >> > >> > Kind Regards, Thomas >> > >> > On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe >> > wrote: >> >> >> >> Thank you Volker! >> >> >> >> I'll restore the original comment and prepare a new webrev. >> >> >> >> ..Thomas >> >> >> >> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis >> >> >> >> wrote: >> >>> >> >>> Hi Thomas, >> >>> >> >>> the change looks good, but I'd prefer if you leave the initial comment >> >>> in place which also mentions "-qminimaltoc" as a way of resolving TOC >> >>> overflow errors. >> >>> >> >>> I actually don't remember exactly, but I think "-qminimaltoc" works by >> >>> creating distinct TOCs for each compilation unit. That comes with an >> >>> performance impact, but "-qpic=large" / "-bbigtoc" can have an >> >>> performance impact as well. >> >>> >> >>> As I said, for the slowdebug build your changes are fine. I'd just >> >>> like to keep the reference to "-qminimaltoc" for the case where we >> >>> have to re-evaluate the different solutions for the product build. >> >>> >> >>> Thank you and best regards, >> >>> Volker >> >>> >> >>> >> >>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph >> >>> wrote: >> >>> > Hi Thomas, >> >>> > >> >>> > the fix looks ok to me. >> >>> > >> >>> > I?m copying build-dev because of the changes in >> >>> > generated-configure.sh. >> >>> > Don?t know if this can just be pushed from extern or if it needs >> >>> > some >> >>> > special handling from Oracle folks or other things to take care of? >> >>> > >> >>> > 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, 17. Juli 2017 12:55 >> >>> > To: ppc-aix-port-dev at openjdk.java.net >> >>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for >> >>> > slowdebug >> >>> > >> >>> > Hi all, >> >>> > >> >>> > may I please have a review for the following fix: >> >>> > >> >>> > webrev: >> >>> > >> >>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/ >> >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344 >> >>> > >> >>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not >> >>> > sure >> >>> > yet which change caused that - I suspect one of the recent >> >>> > template-metaprogramming changes but have not investigated yet. >> >>> > >> >>> > Thanks, Thomas >> >>> > >> >> >> >> >> > > > From kim.barrett at oracle.com Tue Jul 18 23:56:10 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 18 Jul 2017 19:56:10 -0400 Subject: C++11/C++14 support in XLC ? In-Reply-To: <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com> References: <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com> Message-ID: <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com> > On Jun 30, 2017, at 6:08 PM, Kim Barrett wrote: > >> 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. > > [?] > However, just the sheer number of holes in the AIX column is a > significant concern. [?] We're planning another round of compiler upgrades and platform refreshes for the JDK support by Oracle. (Some downstream providers are already building with much more recent compilers.) Absent the XLC++ on AIX deficiencies we would be looking at enabling the use of C++14 as part of that upgrade; all of the other supported compilers can easily handle that. Is there any information that can be shared regarding expected availability of C++11/14 features for XLC++ on AIX? From volker.simonis at gmail.com Wed Jul 19 13:06:13 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 19 Jul 2017 15:06:13 +0200 Subject: C++11/C++14 support in XLC ? In-Reply-To: <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com> References: <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com> <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com> Message-ID: On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett wrote: >> On Jun 30, 2017, at 6:08 PM, Kim Barrett wrote: >> >>> 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. >> >> [?] >> However, just the sheer number of holes in the AIX column is a >> significant concern. [?] > > We're planning another round of compiler upgrades and platform > refreshes for the JDK support by Oracle. (Some downstream providers > are already building with much more recent compilers.) Absent the > XLC++ on AIX deficiencies we would be looking at enabling the use of > C++14 as part of that upgrade; all of the other supported compilers > can easily handle that. Is there any information that can be shared > regarding expected availability of C++11/14 features for XLC++ on AIX? > ..first of all, adding build-dev because that seems to be the most appropriate list for such discussions. For new OpenJDK releases, upgrading the minimal required platforms and compilers is natural and per se OK. Requiring new C++ language features is a much more heavyweight change and needs careful reasoning and discussion: - OpenJDK is not a "pure" open source project. It is also available as a commercial version which Oracle licenses to various customers (including SAP). These customers support more/different platforms than the ones available in the OpenJDK (i.e. we also support HPUX with aCC). That said, this is an OpenJDK mailing list and I won't go into more details here. Such issues should be addressed trough the corresponding license engineering channels. I just wanted to point out that (unfortunately) such a discussion probably won't happen completely in the open. - I suppose the requirement for C++ 14 is planned only for jdk10 and beyond and not for jdk8/jdk9, right? It should be clear however, that once we start using these new C++ features, downports of fixes/features will become increasingly hard. And not only if the fixes/feature uses the new C++ 14 features, but also if they indirectly rely on them. The exact amount of these costs depends on how many fixes/features will be downported in the future. If we really come to a more frequent release model (as discussed in other threads), this may be not that much of a problem. - Related to the previous topic, I suppose you don't plan to upgrade the compiler requirements for already released versions of OpenJDK. Is this correct? - SAP is currently maintaining the AIX port in the OpenJDK and we're willing to do that in the future. But we're not IBM and we can not decide about the XLC feature list. If Oracle and the OpenJDK community finally decide to use C++11/14 features which are not available in XLC we have to live with that. We can either escalate the XLC deficiencies to IBM and suspend the port until the compiler gets fixed. Or we can switch the port to use the GCC tool chain with all the pros (bigger compatibility with Linux platforms) and cons (porting effort, testing, compatibility with other AIX software compiled with XLC, compiler support). While the GCC alternative sounds very appealing at a first glance it really isn't that perfect in reality, especially not for our commercial SAP JVM version of OpenJDK. One problem is the fact that there's no official support for GCC on AIX, the other is compatibility. Just think you had to replace Solaris Studio by GCC on Solaris :) @Tim, Jeff: could you pleas escalate this issue to XLC product management and get back to us with the outcome? Finally, I'm not sure what would be the right format to discuss this issue (maybe a JEP, maybe an enhancement request in JBS, maybe just a mail thread) and how to proceed? Pragmatically, we could already now start to add code which uses new C++ features as long as it is supported on ALL current OpenJDK platforms (and in fact we are already doing this as the recent "type_traits metaprogramming" change 8183927 has demonstrated). Ideally, we would come up with a fixed set of required features to avoid compatibility discussions for every single change. Regards, Volker PS: please don't shoot the messenger :) Personally I'm all for using new compiler features if they deem useful but professionally I get paid for supporting some exotic platforms... > From jrheath at ca.ibm.com Wed Jul 19 13:57:18 2017 From: jrheath at ca.ibm.com (Jeff Heath) Date: Wed, 19 Jul 2017 13:57:18 +0000 Subject: C++11/C++14 support in XLC ? In-Reply-To: References: , <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com> <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Jul 19 22:35:03 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 19 Jul 2017 18:35:03 -0400 Subject: C++11/C++14 support in XLC ? In-Reply-To: References: <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com> <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com> Message-ID: > On Jul 19, 2017, at 9:06 AM, Volker Simonis wrote: > > On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett wrote: >> >> We're planning another round of compiler upgrades and platform >> refreshes for the JDK support by Oracle. > > ..first of all, adding build-dev because that seems to be the most > appropriate list for such discussions. Seems as good as any for now. hotspot-dev might be an alternative, though there?s C++ code elsewhere in the jdk. > For new OpenJDK releases, upgrading the minimal required platforms and > compilers is natural and per se OK. > > Requiring new C++ language features is a much more heavyweight change > and needs careful reasoning and discussion: > > - OpenJDK is not a "pure" open source project. It is also available as > a commercial version which Oracle licenses to various customers > (including SAP). These customers support more/different platforms than > the ones available in the OpenJDK (i.e. we also support HPUX with > aCC). A compiler I'd forgotten about. > That said, this is an OpenJDK mailing list and I won't go into > more details here. Such issues should be addressed trough the > corresponding license engineering channels. I just wanted to point out > that (unfortunately) such a discussion probably won't happen > completely in the open. > > - I suppose the requirement for C++ 14 is planned only for jdk10 and > beyond and not for jdk8/jdk9, right? It should be clear however, that > once we start using these new C++ features, downports of > fixes/features will become increasingly hard. And not only if the > fixes/feature uses the new C++ 14 features, but also if they > indirectly rely on them. The exact amount of these costs depends on > how many fixes/features will be downported in the future. If we really > come to a more frequent release model (as discussed in other threads), > this may be not that much of a problem. I don't think there's any intent to backport such a change. I don't think there's a specific jdk version being targeted yet either; this is all still in a preliminary discussion phase. The possibility of a more frequent release model is one of the considerations. There is also a substantial amount of work to be done to get to that point; there's some problematic code in Hotspot :) > - Related to the previous topic, I suppose you don't plan to upgrade > the compiler requirements for already released versions of OpenJDK. Is > this correct? So far as I know, that's correct. > - SAP is currently maintaining the AIX port in the OpenJDK and we're > willing to do that in the future. But we're not IBM and we can not > decide about the XLC feature list. If Oracle and the OpenJDK community > finally decide to use C++11/14 features which are not available in XLC > we have to live with that. We can either escalate the XLC deficiencies > to IBM and suspend the port until the compiler gets fixed. Or we can > switch the port to use the GCC tool chain with all the pros (bigger > compatibility with Linux platforms) and cons (porting effort, testing, > compatibility with other AIX software compiled with XLC, compiler > support). While the GCC alternative sounds very appealing at a first > glance it really isn't that perfect in reality, especially not for our > commercial SAP JVM version of OpenJDK. One problem is the fact that > there's no official support for GCC on AIX, the other is > compatibility. Just think you had to replace Solaris Studio by GCC on > Solaris :) > > @Tim, Jeff: could you pleas escalate this issue to XLC product > management and get back to us with the outcome? > > Finally, I'm not sure what would be the right format to discuss this > issue (maybe a JEP, maybe an enhancement request in JBS, maybe just a > mail thread) and how to proceed? Right now I think email discussion like we're doing here makes sense. More formality will be needed eventually, but doesn't seem helpful yet. > Pragmatically, we could already now > start to add code which uses new C++ features as long as it is > supported on ALL current OpenJDK platforms (and in fact we are already > doing this as the recent "type_traits metaprogramming" change 8183927 > has demonstrated). I wouldn't describe 8183927 as using new C++ features. There's nothing there that hasn't existed in other C++98 code bases for a long time. C++11 simply codified some existing practice in that area (specifically Boost.TypeTraits). C++11 also includes a number of type traits that are at least hard, if not impossible, to implement in a portable fashion in C++98. So far we haven't required any of those... > Ideally, we would come up with a fixed set of > required features to avoid compatibility discussions for every single > change. I've seen this tried, and it can be pretty hard. For example, Boost has a long list of configuration macros for various C++98/11/14 features; that list is both interesting and daunting. (I don't propose we do anything similar and have multiple implementations based on supported language features. We already have way more than enough of that kind of thing because of multiple platforms.) From dknepprath at tripwire.com Thu Jul 20 00:25:40 2017 From: dknepprath at tripwire.com (David Knepprath) Date: Thu, 20 Jul 2017 00:25:40 +0000 Subject: Unable to download procompiled JDK's Message-ID: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com> I'm trying to download the precompiled JDK to use as bootstrap, but the server is not responsive. For example: http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk_8u40_b13-aix-ppc64.tar.bz2 I filed tickets last week with OpenJDK project and OSUOSL, but they seem to have disappeared into the void. David Knepprath | Software Engineer Direct: 971.313.6480 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Jul 20 06:56:28 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Jul 2017 08:56:28 +0200 Subject: Unable to download procompiled JDK's In-Reply-To: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com> References: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com> Message-ID: Hi, sorry for the confusion. In the past we offered some bootstrap JDK's for AIX for download from our linux/ppc64 osuosl boxes. However, after the machines have been re-imaged at the beginning of the year I haven't set up the webserver again. But as there seems to be a minimal but constant :) demand for AIX bootstrap JDKs I'll set up the server again and update the download links on http://cr.openjdk.java.net/~simonis/ppc-aix-port/. I'll let you know once the new files are in place. Regards, Volker On Thu, Jul 20, 2017 at 2:25 AM, David Knepprath wrote: > I'm trying to download the precompiled JDK to use as bootstrap, but the > server is not responsive. > > For example: > http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk_8u40_b13-aix-ppc64.tar.bz2 > > I filed tickets last week with OpenJDK project and OSUOSL, but they seem to > have disappeared into the void. > > David Knepprath | Software Engineer > > Direct: 971.313.6480 > > > TRIPWIRE | CONFIDENCE: SECURED > www.tripwire.com > > From volker.simonis at gmail.com Thu Jul 20 09:52:16 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Jul 2017 11:52:16 +0200 Subject: Unable to download procompiled JDK's In-Reply-To: References: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com> Message-ID: Hi David, you can now get pre-build AIX binaries which you can use as bootstrap JDKs from the AdoptOpenJDK project: https://adoptopenjdk.net/releases.html#ppc64_aix Regards, Volker On Thu, Jul 20, 2017 at 8:56 AM, Volker Simonis wrote: > Hi, > > sorry for the confusion. In the past we offered some bootstrap JDK's > for AIX for download from our linux/ppc64 osuosl boxes. However, after > the machines have been re-imaged at the beginning of the year I > haven't set up the webserver again. > > But as there seems to be a minimal but constant :) demand for AIX > bootstrap JDKs I'll set up the server again and update the download > links on http://cr.openjdk.java.net/~simonis/ppc-aix-port/. I'll let > you know once the new files are in place. > > Regards, > Volker > > On Thu, Jul 20, 2017 at 2:25 AM, David Knepprath > wrote: >> I'm trying to download the precompiled JDK to use as bootstrap, but the >> server is not responsive. >> >> For example: >> http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk_8u40_b13-aix-ppc64.tar.bz2 >> >> I filed tickets last week with OpenJDK project and OSUOSL, but they seem to >> have disappeared into the void. >> >> David Knepprath | Software Engineer >> >> Direct: 971.313.6480 >> >> >> TRIPWIRE | CONFIDENCE: SECURED >> www.tripwire.com >> >> From dknepprath at tripwire.com Thu Jul 20 20:52:16 2017 From: dknepprath at tripwire.com (David Knepprath) Date: Thu, 20 Jul 2017 20:52:16 +0000 Subject: Unable to download procompiled JDK's In-Reply-To: References: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com> , Message-ID: <2156689F0BE77047BB765BEFF22794D4011F1200@PDXMB01.tripwire.com> Thanks Volker! I'm running in to some issues with the binary, could you add me to the slack channel? What are the requirements for these builds? On AIX 7.1 I get the following error: ./java -version Error: dl failure on line 893 Error: failed /tmp/jdk8u141-b15/jre/lib/ppc64/server/libjvm.so, because 0509-130 Symbol resolution failed for /tmp/jdk8u141-b15/jre/lib/ppc64/server/libjvm.so because: 0509-136 Symbol __setjmp (number 50) is not exported from dependent module /usr/lib/libc.a[shr_64.o]. 0509-022 Cannot load module /tmp/jdk8u141-b15/jre/lib/ppc64/server/libjvm.so. 0509-026 System error: Cannot run a file that does not have a valid format. 0509-192 Examine .loader section symbols with the 'dump -Tv' command. David Knepprath | Software Engineer Direct: 971.313.6480 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________________ From: Volker Simonis [volker.simonis at gmail.com] Sent: Thursday, July 20, 2017 2:52 AM To: David Knepprath Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: Unable to download procompiled JDK's Hi David, you can now get pre-build AIX binaries which you can use as bootstrap JDKs from the AdoptOpenJDK project: https://adoptopenjdk.net/releases.html#ppc64_aix Regards, Volker On Thu, Jul 20, 2017 at 8:56 AM, Volker Simonis wrote: > Hi, > > sorry for the confusion. In the past we offered some bootstrap JDK's > for AIX for download from our linux/ppc64 osuosl boxes. However, after > the machines have been re-imaged at the beginning of the year I > haven't set up the webserver again. > > But as there seems to be a minimal but constant :) demand for AIX > bootstrap JDKs I'll set up the server again and update the download > links on http://cr.openjdk.java.net/~simonis/ppc-aix-port/. I'll let > you know once the new files are in place. > > Regards, > Volker > > On Thu, Jul 20, 2017 at 2:25 AM, David Knepprath > wrote: >> I'm trying to download the precompiled JDK to use as bootstrap, but the >> server is not responsive. >> >> For example: >> http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk_8u40_b13-aix-ppc64.tar.bz2 >> >> I filed tickets last week with OpenJDK project and OSUOSL, but they seem to >> have disappeared into the void. >> >> David Knepprath | Software Engineer >> >> Direct: 971.313.6480 >> >> >> TRIPWIRE | CONFIDENCE: SECURED >> www.tripwire.com >> >> From volker.simonis at gmail.com Fri Jul 21 08:01:37 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Jul 2017 10:01:37 +0200 Subject: Unable to download procompiled JDK's In-Reply-To: <2156689F0BE77047BB765BEFF22794D4011F1200@PDXMB01.tripwire.com> References: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com> <2156689F0BE77047BB765BEFF22794D4011F1200@PDXMB01.tripwire.com> Message-ID: Hi David, yes that's a known problem because the AdoptOpenJDK colleagues are apparently still building on AIX 7.2. I've added you to the Slack channel now (you should receive an invitation email). You can find there an older openjdk7 build which should run on AIX 5.3 and newer (https://adoptopenjdk.slack.com/files/simonis/F5VQR3B9R/openjdk-7u-aix.tgz). Please use that as only as bootstrap jdk. Regards, Volker On Thu, Jul 20, 2017 at 10:52 PM, David Knepprath wrote: > Thanks Volker! > > I'm running in to some issues with the binary, could you add me to the slack channel? > > What are the requirements for these builds? On AIX 7.1 I get the following error: > > ./java -version > Error: dl failure on line 893 > Error: failed /tmp/jdk8u141-b15/jre/lib/ppc64/server/libjvm.so, because 0509-130 Symbol resolution failed for /tmp/jdk8u141-b15/jre/lib/ppc64/server/libjvm.so because: > 0509-136 Symbol __setjmp (number 50) is not exported from > dependent module /usr/lib/libc.a[shr_64.o]. > 0509-022 Cannot load module /tmp/jdk8u141-b15/jre/lib/ppc64/server/libjvm.so. > 0509-026 System error: Cannot run a file that does not have a valid format. > 0509-192 Examine .loader section symbols with the > 'dump -Tv' command. > > > David Knepprath | Software Engineer > Direct: 971.313.6480 > > TRIPWIRE | CONFIDENCE: SECURED > www.tripwire.com > > > ________________________________________ > From: Volker Simonis [volker.simonis at gmail.com] > Sent: Thursday, July 20, 2017 2:52 AM > To: David Knepprath > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: Unable to download procompiled JDK's > > Hi David, > > you can now get pre-build AIX binaries which you can use as bootstrap > JDKs from the AdoptOpenJDK project: > > https://adoptopenjdk.net/releases.html#ppc64_aix > > Regards, > Volker > > > On Thu, Jul 20, 2017 at 8:56 AM, Volker Simonis > wrote: >> Hi, >> >> sorry for the confusion. In the past we offered some bootstrap JDK's >> for AIX for download from our linux/ppc64 osuosl boxes. However, after >> the machines have been re-imaged at the beginning of the year I >> haven't set up the webserver again. >> >> But as there seems to be a minimal but constant :) demand for AIX >> bootstrap JDKs I'll set up the server again and update the download >> links on http://cr.openjdk.java.net/~simonis/ppc-aix-port/. I'll let >> you know once the new files are in place. >> >> Regards, >> Volker >> >> On Thu, Jul 20, 2017 at 2:25 AM, David Knepprath >> wrote: >>> I'm trying to download the precompiled JDK to use as bootstrap, but the >>> server is not responsive. >>> >>> For example: >>> http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk_8u40_b13-aix-ppc64.tar.bz2 >>> >>> I filed tickets last week with OpenJDK project and OSUOSL, but they seem to >>> have disappeared into the void. >>> >>> David Knepprath | Software Engineer >>> >>> Direct: 971.313.6480 >>> >>> >>> TRIPWIRE | CONFIDENCE: SECURED >>> www.tripwire.com >>> >>> >