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: <OFBB2C46E8.6F0BE2D7-ON49258152.002EA734-49258152.002EEBC0@notes.na.collabserv.com>

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" <christoph.langer at sap.com>
To:     Kazunori Ogata <OGATAK at jp.ibm.com>, "nio-dev at openjdk.java.net" 
<nio-dev at openjdk.java.net>
Cc:     core-libs-dev <core-libs-dev at openjdk.java.net>
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 <sean.coffey at oracle.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev 
<core-libs-
> 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 <sean.coffey at oracle.com> wrote on 2017/06/30 23:57:25:
> 
> > From: Se?n Coffey <sean.coffey at oracle.com>
> > To: Kazunori Ogata <OGATAK at jp.ibm.com>, "Langer, Christoph"
> > <christoph.langer at sap.com>
> > Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
> > dev at openjdk.java.net>, core-libs-dev <core-libs-dev at openjdk.java.net>,
> > "nio-dev at openjdk.java.net" <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" <christoph.langer at sap.com> wrote on 2017/06/28
> > > 21:04:36:
> > >
> > >> From: "Langer, Christoph" <christoph.langer at sap.com>
> > >> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> > >> Cc: Alan Bateman <Alan.Bateman at oracle.com>, Claes Redestad
> > >> <claes.redestad at oracle.com>, core-libs-dev <core-libs-
> > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" <nio-
> > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net"
> > > <ppc-aix-port-
> > >> 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>
 <b7b2c51e623146ed92230bd3c74c327b@sap.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: <CA+3eh10jae2Y79oN7Z_CNXeKQmLmWDfdBjFCJO0yw85AfE-QCg@mail.gmail.com>

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
<mbrandy at linux.vnet.ibm.com> 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' <mbrandy at linux.vnet.ibm.com>;
>> 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 <mbrandy at linux.vnet.ibm.com>
>>
>> (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 <martin.doerr at sap.com>;
>> 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 <martin.doerr at sap.com>;
>>> 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: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>

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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170717/5709a1be/attachment.html>

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: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170717/a9eaf688/attachment.html>

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: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
Message-ID: <CAA-vtUyKeXBvnE5cCDvOO0f0kVq0eW2PzX9rWJ_cA3gvxipaYQ@mail.gmail.com>

Thank you Christoph!

On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph <christoph.langer at sap.com
> 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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170717/59b9a502/attachment.html>

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: <CAA-vtUyKeXBvnE5cCDvOO0f0kVq0eW2PzX9rWJ_cA3gvxipaYQ@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CAA-vtUyKeXBvnE5cCDvOO0f0kVq0eW2PzX9rWJ_cA3gvxipaYQ@mail.gmail.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: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
Message-ID: <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>

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
<christoph.langer at sap.com> 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: <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
Message-ID: <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>

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
> <christoph.langer at sap.com> 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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170718/d263409a/attachment-0001.html>

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: <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
Message-ID: <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>

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 <thomas.stuefe at gmail.com>
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
>> <christoph.langer at sap.com> 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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170718/38ab6d9b/attachment.html>

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: <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
Message-ID: <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>

Looks good!

Thanks,
Volker

On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com> 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 <thomas.stuefe at gmail.com>
> 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
>>> <christoph.langer at sap.com> 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: <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
 <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
Message-ID: <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>

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 <volker.simonis at gmail.com>
wrote:

> Looks good!
>
> Thanks,
> Volker
>
> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> 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 <thomas.stuefe at gmail.com>
> > 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
> >>> <christoph.langer at sap.com> 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: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170718/3b57c6c8/attachment.html>

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: <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
 <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
 <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>
Message-ID: <CA+3eh10gu=71=mMz0Q5uJRqv+nMioQZ6u1EyA1r0WuWi7a1apw@mail.gmail.com>

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 <thomas.stuefe at gmail.com> 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 <volker.simonis at gmail.com>
> wrote:
>>
>> Looks good!
>>
>> Thanks,
>> Volker
>>
>> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> 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 <thomas.stuefe at gmail.com>
>> > 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
>> >>> <christoph.langer at sap.com> 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: <OFC998CE95.664CE6A1-ON8025814B.00305A4B-8025814B.00306D2D@LocalDomain>
 <OF8F25A920.5614A9EC-ON0025814E.00730630-8525814E.0074F488@notes.na.collabserv.com>
 <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 <kim.barrett at oracle.com> wrote:
> 
>> On Jun 29, 2017, at 5:17 PM, Jeff Heath <jrheath at ca.ibm.com> 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: <OFC998CE95.664CE6A1-ON8025814B.00305A4B-8025814B.00306D2D@LocalDomain>
 <OF8F25A920.5614A9EC-ON0025814E.00730630-8525814E.0074F488@notes.na.collabserv.com>
 <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com>
 <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com>
Message-ID: <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>

On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Jun 30, 2017, at 6:08 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Jun 29, 2017, at 5:17 PM, Jeff Heath <jrheath at ca.ibm.com> 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: <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>
References: <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>,
 <OFC998CE95.664CE6A1-ON8025814B.00305A4B-8025814B.00306D2D@LocalDomain>
 <OF8F25A920.5614A9EC-ON0025814E.00730630-8525814E.0074F488@notes.na.collabserv.com>
 <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com>
 <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com>
Message-ID: <OF83022439.87701CD7-ON00258162.004C31CC-00258162.004CA893@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170719/2e697e00/attachment.html>

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: <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>
References: <OFC998CE95.664CE6A1-ON8025814B.00305A4B-8025814B.00306D2D@LocalDomain>
 <OF8F25A920.5614A9EC-ON0025814E.00730630-8525814E.0074F488@notes.na.collabserv.com>
 <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com>
 <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com>
 <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>
Message-ID: <C05FB9AE-63AD-44B7-9BE6-E2461E557B86@oracle.com>

> On Jul 19, 2017, at 9:06 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett <kim.barrett at oracle.com> 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<https://mail.tripwire.com/owa/redir.aspx?SURL=MohT1BI4Wq2vEdF8QWI0O35XRNxiappm16zk9FDYybvOgApuqrHTCGgAdAB0AHAAOgAvAC8AdwB3AHcALgB0AHIAaQBwAHcAaQByAGUALgBjAG8AbQA.&URL=http%3a%2f%2fwww.tripwire.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170720/0b776ef2/attachment-0001.html>

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: <CA+3eh12EzQMWz8BcLXOxKaKURWUti_kMc7W071kM+RQhFkY=8g@mail.gmail.com>

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
<dknepprath at tripwire.com> 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: <CA+3eh12EzQMWz8BcLXOxKaKURWUti_kMc7W071kM+RQhFkY=8g@mail.gmail.com>
References: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com>
 <CA+3eh12EzQMWz8BcLXOxKaKURWUti_kMc7W071kM+RQhFkY=8g@mail.gmail.com>
Message-ID: <CA+3eh12R220S29KWDJ2hd5pHBh70rs1ziT3dqbu2TwTf8PL0FQ@mail.gmail.com>

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
<volker.simonis at gmail.com> 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
> <dknepprath at tripwire.com> 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: <CA+3eh12R220S29KWDJ2hd5pHBh70rs1ziT3dqbu2TwTf8PL0FQ@mail.gmail.com>
References: <2156689F0BE77047BB765BEFF22794D4011F06CA@PDXMB01.tripwire.com>
 <CA+3eh12EzQMWz8BcLXOxKaKURWUti_kMc7W071kM+RQhFkY=8g@mail.gmail.com>,
 <CA+3eh12R220S29KWDJ2hd5pHBh70rs1ziT3dqbu2TwTf8PL0FQ@mail.gmail.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
<volker.simonis at gmail.com> 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
> <dknepprath at tripwire.com> 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>
 <CA+3eh12EzQMWz8BcLXOxKaKURWUti_kMc7W071kM+RQhFkY=8g@mail.gmail.com>
 <CA+3eh12R220S29KWDJ2hd5pHBh70rs1ziT3dqbu2TwTf8PL0FQ@mail.gmail.com>
 <2156689F0BE77047BB765BEFF22794D4011F1200@PDXMB01.tripwire.com>
Message-ID: <CA+3eh10egtk_q7kJV1DK4A=UKXSXCM9ob+3VKr==OkDUaFDXag@mail.gmail.com>

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
<dknepprath at tripwire.com> 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
> <volker.simonis at gmail.com> 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
>> <dknepprath at tripwire.com> 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
>>>
>>>
>