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

Re: Fw: C++11/C++14 support in XLC ?
by Jeff Heath 19 Jul '17

19 Jul '17

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-… Regards, Jeff -------- Forwarded Message -------- Subject: C++11/C++14 support in XLC ? Date: Fri, 23 Jun 2017 09:14:09 +0200 From: Volker Simonis <volker.simonis(a)gmail.com> To: ppc-aix-port-dev(a)openjdk.java.net <ppc-aix-port-dev(a)openjdk.java.net> CC: Kim Barrett <kim.barrett(a)oracle.com> Hi everybody, Kim recently approached me with some questions regarding the amount and quality of C++11/C++14 support in XLC (see his mail below). As he found out, it seems that there's unfortunately not much of even C++11 support in recent XLC compilers [1,2]. I think, one of the features most badly needed is the support for atomics operations library [3] which was introduced with C++11. A recent hotspot mail thread [4,5] may give an impression why the atomics library is need (but obviously only makes sense if it is high-quality, bullet-proof on all supported platforms) I would be great if somebody from the IBM folks on this list could provide some more detailed information on the current state of the C++11/C++14/C++XX support in XLC and the future plans if possible. Thank you and best regards, Volker ---------- Forwarded message ---------- From: Kim Barrett <kim.barrett(a)oracle.com> Date: Wed, Jun 21, 2017 at 6:23 AM Subject: c++11 ? To: Volker Simonis <volker.simonis(a)gmail.com> Hi Volker, There's been a lot of internal discussion here at Oracle about possibly updating compilers and starting to use C++11 or even C++14 features, for JDK10 or beyond. Until recently I thought C++11 was practical, just a matter of doing the work. This was based in part on information I'd seen about XLC++ supporting C++11. However, I recently found documentation [1] [2] indicating that's only true for the Linux port, and that even the latest version of the AIX port is seriously laggard, only providing a few specific C++11 features. If that's accurate, that's very disappointing. I was wondering if you or your group might have any additional information or thoughts? [1] https://www-03.ibm.com/software/products/en/xlcpp-aix [2] https://www-01.ibm.com/support/docview.wss?uid=swg27047114 [3] http://en.cppreference.com/w/cpp/atomic [4] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-May/thread.html#224 [5] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/thread.html#268

3 6

RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
by Thomas Stüfe 18 Jul '17

18 Jul '17

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/w… 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

4 9

RFR(M) JDK-8181809 PPC64: Leverage mtfprd/mffprd on POWER8
by Matthew Brandyberry 04 Jul '17

04 Jul '17

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

4 14

Fw: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel()
by Kazunori Ogata 03 Jul '17

03 Jul '17

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(a)sap.com> To: Kazunori Ogata <OGATAK(a)jp.ibm.com>, "nio-dev(a)openjdk.java.net" <nio-dev(a)openjdk.java.net> Cc: core-libs-dev <core-libs-dev(a)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@jp.ibm.com] > Sent: Freitag, 30. Juni 2017 20:31 > To: Seán Coffey <sean.coffey(a)oracle.com> > Cc: Langer, Christoph <christoph.langer(a)sap.com>; core-libs-dev <core-libs- > dev(a)openjdk.java.net>; nio-dev(a)openjdk.java.net; ppc-aix-port- > dev(a)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(a)oracle.com> wrote on 2017/06/30 23:57:25: > > > From: Seán Coffey <sean.coffey(a)oracle.com> > > To: Kazunori Ogata <OGATAK(a)jp.ibm.com>, "Langer, Christoph" > > <christoph.langer(a)sap.com> > > Cc: "ppc-aix-port-dev(a)openjdk.java.net" <ppc-aix-port- > > dev(a)openjdk.java.net>, core-libs-dev <core-libs-dev(a)openjdk.java.net>, > > "nio-dev(a)openjdk.java.net" <nio-dev(a)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(a)sap.com> wrote on 2017/06/28 > > > 21:04:36: > > > > > >> From: "Langer, Christoph" <christoph.langer(a)sap.com> > > >> To: Kazunori Ogata <OGATAK(a)jp.ibm.com> > > >> Cc: Alan Bateman <Alan.Bateman(a)oracle.com>, Claes Redestad > > >> <claes.redestad(a)oracle.com>, core-libs-dev <core-libs- > > >> dev(a)openjdk.java.net>, "nio-dev(a)openjdk.java.net" <nio- > > >> dev(a)openjdk.java.net>, "ppc-aix-port-dev(a)openjdk.java.net" > > > <ppc-aix-port- > > >> dev(a)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 > > >> > > > > > >

1 0

RFR: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()
by Kazunori Ogata 30 Jun '17

30 Jun '17

Hi all, please review a change for JDK-8182743. Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743 Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ This change removes a "volatile" qualifier of a static variable used by Charset.atBugLevel() because it does not improve thread-safety of the code and it hurts performance on PPC (and should be the same in ARM, too). Removing the "volatile" improved performance by 26% in a POWER8 machine using following micro benchmark: ------ import java.io.*; import java.nio.ByteBuffer; import java.nio.charset.Charset; import java.util.ArrayList; class ConvertTest { static String str; public static void main(String[] args) { byte buf[] = { 0x41 }; Charset fromCharset = Charset.forName("iso-8859-1"); long start = System.currentTimeMillis(); for(long i = 0; i < 100000000; i++) str = new String(buf, 0, 1, fromCharset); long end = System.currentTimeMillis(); System.out.println("Elapsed: "+(end-start)+" ms"); } } ------ Regards, Ogata

7 27

OpenJDK on BullFreeware
by REIX, Tony 30 Jun '17

30 Jun '17

Hi, I am one of the maintainers of the BullFreeware web-site where RPMs of OpenSource packages for AIX are available (for free): http://www.bullfreeware.com . I'd like to know: - what is the status of this port of OpenJDK on AIX (is it usable in production ?), - where are the sources and the instructions for building it, and - if there already exists a RPM .spec file for building RPMs. Thanks/Regards, Cordialement, Tony Reix Bull - ATOS IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 Échirolles - France www.atos.net

2 1

RFR(s): [aix]: 8182984: [aix] Make stack traces independent on successful vm initialization
by Thomas Stüfe 28 Jun '17

28 Jun '17

Hi all, please review, at your convenience, the following AIX-only fix: Issue: https://bugs.openjdk.java.net/browse/JDK-8182984 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182984-aix- better-stacktraces/webrev.00/webrev/ In short, it improves the chances of getting better callstacks if the VM crashes or asserts before os::init() ran or if os::init() ran into an error. Details: callstack printing is implemented in our porting layer (porting_aix.hpp/cpp), in "AixNativeCallstack::print_ callstack_for_context()". This change makes this independent from VM infrastructure (it should be, because the porting layer should be below the hotspot and should not have dependencies into it). For one, it is not necessary to use Thread::current() to get the current threads stack bounds, because that requires pthread TLS being initialized successfully and a current Thread* to exist. For the purpose of stack trace printing, we can just call pthread_getthrds_np(). Then, we use os::vm_page_size() to align the lower stack boundary to the stack page size (to place our guard pages later). This is a hotspot implementation detail and does not have to be done in the porting layer, but should be moved upward to os::current_stack_size(). Thank you for reviewing, Kind Regards, Thomas

3 3

Failed to download the bootstrap JDK
by Gordon_CY_Wu＠amat.com 27 Jun '17

27 Jun '17

Hi, All I am trying to download the bootstrap JDK ( openjdk1.7.0-ppc-aix-port-aix-ppc64-b03.tar.bz2<http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk1.7.0-ppc-…> openjdk_8u40_b13-aix-ppc64.tar.bz2<http://openjdkpower.osuosl.org/OpenJDK/download/bootstrap/openjdk_8u40_b13-…>. ) following the link from http://cr.openjdk.java.net/~simonis/ppc-aix-port<http://cr.openjdk.java.net/~simonis/ppc-aix-port/>, but did not succeed. Are those files still existed? Where can I download the files, so I can build the openjdk for AIX on my AIX system? Thanks and Regards Gordon CY Wu Support Engineer|TPS | Automation Products AGS | Applied Materials Office 801.736.3347| Mobile 801.380.5910 | Support Hot Line 801.488.2277 The content of this message is Applied Materials Confidential. If you are not the intended recipient and have received this message in error, any use or distribution is prohibited. Please notify me immediately by reply e-mail and delete this message from your computer system. Thank you. P Save a tree. Please don't print this e-mail unless needed. ________________________________

2 3

Fw: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()
by Kazunori Ogata 27 Jun '17

27 Jun '17

Hi, I'm re-posting this mail because I sent the old one before I subscribe core-libs-dev and nio-dev. Sorry if you receive this mail twice. Regards, Ogata ----- Forwarded by Kazunori Ogata/Japan/IBM on 2017/06/27 17:28 ----- "ppc-aix-port-dev" <ppc-aix-port-dev-bounces(a)openjdk.java.net> wrote on 2017/06/27 17:12:45: > From: "Kazunori Ogata" <OGATAK(a)jp.ibm.com> > To: Aleksey Shipilev <shade(a)redhat.com> > Cc: core-libs-dev <core-libs-dev(a)openjdk.java.net>, "nio- > dev(a)openjdk.java.net" <nio-dev(a)openjdk.java.net>, "ppc-aix-port- > dev(a)openjdk.java.net" <ppc-aix-port-dev(a)openjdk.java.net> > Date: 2017/06/27 17:13 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > Sent by: "ppc-aix-port-dev" <ppc-aix-port-dev-bounces(a)openjdk.java.net> > > Hi Christoph, > > Thank you for redirecting this request to appropriate mailing lists. > > > Hi Aleksey, > > Thank you for reviewing the patch. > > > Regards, > Ogata > > > Aleksey Shipilev <shade(a)redhat.com> wrote on 2017/06/27 15:58:56: > > > From: Aleksey Shipilev <shade(a)redhat.com> > > To: "Langer, Christoph" <christoph.langer(a)sap.com>, Kazunori Ogata > > <OGATAK(a)jp.ibm.com>, core-libs-dev <core-libs-dev(a)openjdk.java.net>, > "nio- > > dev(a)openjdk.java.net" <nio-dev(a)openjdk.java.net> > > Cc: "ppc-aix-port-dev(a)openjdk.java.net" > <ppc-aix-port-dev(a)openjdk.java.net> > > Date: 2017/06/27 15:59 > > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > On 06/27/2017 08:50 AM, Langer, Christoph wrote: > > > So, waiting for comments from other experts... > > > > >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ > > > > This patch is fine as stated. > > > > Without volatile, there is a benign data race on the bugLevel field, > which is > > okay, assuming "sun.nio.cs.bugLevel" never actually changes. Doing > > double-checked-locking seems excessive here, because we can accept more > than one > > invocation of privilegedGetProperty. > > > > -Aleksey > > > > > > > > > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] >

1 0

RFR(xxs): 8182864: [aix] os::print_native_callstack should not assert for primordial threadness
by Thomas Stüfe 26 Jun '17

26 Jun '17

Hi all, may I please get reviews for this tiny change: Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8182864-aix-do-not-assert-in-pri… Issue: https://bugs.openjdk.java.net/browse/JDK-8182864 In short, this fix removes some asserts from os::print_native_callstack() (via os::Aix::query_stack_dimensions()) which are not really useful. We assert that we do not run on the primordial thread, because otherwise the API used to retrieve the stack dimensions may fail. This is wrong on two accounts: 1) the API now works for the primordial thread too, and does so since AIX 5.3 (?) and 2) this is not the right place to assert for the primordial thread, because the stack trace shall always work. The assert prevented us to get stack traces in some corner cases where we would have been perfectly able to get them. For more background on the primordial thread issue on AIX, please see https://bugs.openjdk.java.net/browse/JDK-8171505 Thanks! Thomas

3 4