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

Re: [8u] RFR for backport of 8154156: PPC64: improve array copy stubs by using vector instructions
by Kazunori Ogata 08 Jan '19

08 Jan '19

Hi, Ping. Can anyone review this enhancement backport request? Regards, Ogata Kazunori Ogata/Japan/IBM wrote on 2018/12/18 23:41:16: > From: Kazunori Ogata/Japan/IBM > To: hotspot-compiler-dev(a)openjdk.java.net, ppc-aix-port-dev(a)openjdk.java.net > Date: 2018/12/18 23:41 > Subject: [8u] RFR for backport of 8154156: PPC64: improve array copy stubs > by using vector instructions > > Hi, > > May I get review for enhancement backport of 8154156: PPC64: improve array > copy stubs by using vector instructions? > > To make this patch buildable (and usable by other planned backports listed > in [1]), I cherry picked config_dscr() and its dependent code from [2,3] > and has_mfdscr() from [4]. > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e > Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.01/ > > I confirmed it was buildable for both relase and fastdebug builds, and > JTREG caused no degradation. > > Refs: > [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-December/ > 003818.html > [2] 8149655: PPC64: Implement CompactString intrinsics > http://hg.openjdk.java.net/jdk/jdk/rev/6241574f5982 > [3] 8080684: PPC64: Fix little-endian build after "8077838: Recent > developments for ppc" > http://hg.openjdk.java.net/jdk/jdk/rev/12ccf8b26eb0 > [4] 8077838: Recent developments for ppc. > http://hg.openjdk.java.net/jdk/jdk/rev/c703c89fddbf > > Regards, > Ogata

2 2

[8u] RFR for backport of 8154156: PPC64: improve array copy stubs by using vector instructions
by Kazunori Ogata 18 Dec '18

18 Dec '18

Hi, May I get review for enhancement backport of 8154156: PPC64: improve array copy stubs by using vector instructions? To make this patch buildable (and usable by other planned backports listed in [1]), I cherry picked config_dscr() and its dependent code from [2,3] and has_mfdscr() from [4]. Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.01/ I confirmed it was buildable for both relase and fastdebug builds, and JTREG caused no degradation. Refs: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-December/00381… [2] 8149655: PPC64: Implement CompactString intrinsics http://hg.openjdk.java.net/jdk/jdk/rev/6241574f5982 [3] 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" http://hg.openjdk.java.net/jdk/jdk/rev/12ccf8b26eb0 [4] 8077838: Recent developments for ppc. http://hg.openjdk.java.net/jdk/jdk/rev/c703c89fddbf Regards, Ogata

1 0

RFR: 8215262: PPC64: FMA Vectorization on PPC64
by Michihiro Horie 13 Dec '18

13 Dec '18

Dear all, Would you please review the following change? This change supports FMA vectorization on PPC64. Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java It showed ~50% reduction in the execution time. I also tested with JTREG and there was no difference in the results compared to the original. Best regards, -- Michihiro, IBM Research - Tokyo

3 7

[8u] RFR(v2) for backport of JDK-8188868: PPC64: Support AES intrinsics on Big Endian
by Kazunori Ogata 11 Dec '18

11 Dec '18

Hi, May I get reviews for revised request for enhancement backport of JDK-8188868: PPC64: Support AES intrinsics on Big Endian [12]? After the discussion in Nov. [13], I found that some older patches also need to be backported to reduce the amount of manual changes. So the following is the final list (newer one first) of backported patches, with comments how I modified them. I ran JTREG in CentOS7 BE on POWER8 using each of debug build after applying [4] and newer and the release build of [1], and found no degradation by these patches. I also verified that the code [1] was built and ran in Ubuntu ppc64le correctly. [1] 8188868: PPC64: Support AES intrinsics on Big Endian Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/9d337e48b178 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8188868/webrev.01/ Comments: No conflict. [2] 8185979: PPC64: Implement SHA2 intrinsic Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/f4962ab855b6 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.01/ Comments: Fixed difference of intrinsic calling convention by passing additional argument word for each Long parameter. Also modified test code support ppc. [3] 8185969: PPC64: Improve VSR support to use up to 64 registers Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/057f21a10f5f Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.01/ Comments: Cherry picked MTVSRWA_OPCODE from [11]. [4] 8185975: PPC64: Fix vsldoi interface according to the ISA Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/1bf8c1e8b79a Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185975/webrev.01/ Comments: Applied cleanly. This is the same change as what Gustavo requested RFA to 8u-dev ML last week [14] (besides the copyright dates because they are already updated in the patches below). Since this patch has no conflict with other changes, we can skip this one when [14] was approved. [5] 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/f1e6a21095f5 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8166684/webrev.01/ Comments: Applied cleanly. [6] 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.01/ Comments: No conflict, but applied manually because patch command got confused and failed to find the code to apply. [7] 8154156: PPC64: improve array copy stubs by using vector instructions Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.01/ Comments: This patch cherry picked config_dscr() and its dependent code from [9,10] and has_mfdscr() from [8]. Cherry picked patches: [8] 8149655: PPC64: Implement CompactString intrinsics http://hg.openjdk.java.net/jdk/jdk/rev/6241574f5982 [9] 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" http://hg.openjdk.java.net/jdk/jdk/rev/12ccf8b26eb0 [10] 8077838: Recent developments for ppc. http://hg.openjdk.java.net/jdk/jdk/rev/c703c89fddbf [11] 8181809: PPC64: Leverage mtfprd/mffprd on POWER8 http://hg.openjdk.java.net/jdk/jdk/rev/3fd9b25850f4 Other references: [12] https://bugs.openjdk.java.net/browse/JDK-8188868 [13] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-November/00374… [14] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008276.html Regards, Ogata

1 0

JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work.
by Steve Groeger 07 Dec '18

07 Dec '18

Hi all, I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 @@ -446,7 +446,7 @@ ProcessBuilder.NullOutputStream.INSTANCE : new ProcessPipeOutputStream(fds[0]); - stdout = (fds[1] == -1) ? + stdout = (fds[1] == -1 || forceNullOutputStream) ? ProcessBuilder.NullInputStream.INSTANCE : new DeferredCloseProcessPipeInputStream(fds[1]); I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

3 4

RFR: 8212676 AIX's CDE/MWM support
by Ichiroh Takiguchi 05 Dec '18

05 Dec '18

Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ Test instructions and screen shots are in JDK-8212676. GUI environment for AIX platform still needs CDE support. This fix is required to avoid unexpected working behavior on AIX platform. I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-06-18 18:57, Ichiroh Takiguchi wrote: > Hello. > > This fix is really required for AIX's GUI. > System color setting and window manager's working behavior are very > important. > > I appreciate any feedback, and how I would go about obtaining a > sponsor and contributor ? > > On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> webrev file was extracted. >> Please see >> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >> >> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> Webrev.zip file is stored into >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>> >>> Test programs are also stored: >>> No testcase is available for FontUtilities.java and >>> XDecoratedPeer.java. >>> >>> MotifColorUtilities.java >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>> Run SystemColorTest2, system colors should be displayed >>> AIX sample is >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>> >>> XWM.java >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>> On AIX CDE, isMotif and isCDE were true. >>> On AIX MWM, every entry is false. >>> >>> XWindowPeer.java >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>> On AIX CDE, click inside of "Non-Focusable" window (not window >>> frame). >>> Window focus should not be changed because of "click on focus" >>> feature. >>> But input focus is moved to "Non-Focusable" window. >>> >>> >>> On 2018-05-18 01:00, Phil Race wrote: >>>> I think we'd need to see the actual proposed changes and understand >>>> the implications >>>> for ongoing support as we no longer support any platform which has a >>>> CDE desktop. >>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >>>> such support rather >>>> than adding to it. >>>> >>>> -phil. >>>> >>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>> Hello, >>>>> IBM would like to contribute AIX's CDE (Common Desktop Environment) >>>>> DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support >>>>> to OpenJDK project. >>>>> >>>>> I'd like contribute following 5 files: >>>>> >>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>> M >>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>> (Add High Color support on CDE, OpenJDK just supports Medium Color) >>>>> [1] >>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>> XMapRaised/XMapWindow) >>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>> (Detect MWM on AIX platform) >>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>> DTWM/MWM does not have enough features for ICCCM) >>>>> >>>>> I appreciate any feedback please, and how I would go about >>>>> obtaining a sponsor and contributor ? >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> [1] >>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.ht… >>>>>

3 4

RFR(XS): 8214063: [AIX] Disable symbol visibility flags
by Volker Simonis 04 Dec '18

04 Dec '18

Hi, can I please have a review for the following trivial change which simply disables the symbol visibility flags on AIX: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ https://bugs.openjdk.java.net/browse/JDK-8214063 Change "8202322: AIX: symbol visibility flags not support on xlc 12.1" [1] blindly introduced these flags for all xlC compiler versions > 12.1 without ever testing it (which should not have happened). Now that people are starting to really use xlC 13 it turns out that there is more to do than just enabling the flags. This future work is covered by "8204541: Correctly support AIX xlC 13.1 symbol visibility flags". Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8202322 [2] https://bugs.openjdk.java.net/browse/JDK-8204541

6 10

Definition of CRC32 helper generate_load_table_addr() is absent
by Gustavo Romero 28 Nov '18

28 Nov '18

Hello Lutz, It looks like that generate_load_table_addr() prototype in CRC32 code is not defined anywhere, so I'm wondering if it's a leftover and must be removed. Should I contribute with a trivial fix like the following? diff -r 263c7685a22a src/hotspot/cpu/ppc/stubRoutines_ppc.hpp --- a/src/hotspot/cpu/ppc/stubRoutines_ppc.hpp Wed Nov 28 13:24:56 2018 +0300 +++ b/src/hotspot/cpu/ppc/stubRoutines_ppc.hpp Wed Nov 28 06:54:52 2018 -0500 @@ -62,7 +62,6 @@ public: // CRC32 Intrinsics. - static void generate_load_table_addr(MacroAssembler* masm, Register table, address table_addr, uint64_t table_contents); static void generate_load_crc_table_addr(MacroAssembler* masm, Register table); static void generate_load_crc_constants_addr(MacroAssembler* masm, Register table); static void generate_load_crc_barret_constants_addr(MacroAssembler* masm, Register table); Best regards, Gustavo

3 7

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it
by Volker Simonis 27 Nov '18

27 Nov '18

Hi Phil, I'd like to kindly ask you to suggest how we can proceed with this issue. As I wrote before, Xrandr is not officially supported on AIX and there are no official packages available for it. There are some OpenSource sites for AIX which provide Xrandr, but they are all not compatible with the default native libraries (e.g. the open source Xrandr package depends on another open source package of Xrender.so.1 but the system only provides Xrender.so.0 natively). We can't compile the whole JDK (i.e. libawt_xawt.so) against some open source package of Xrender.so.1 because that simply won't be available on the majority of systems. Remember that forcing people to install these open-source packages even as a build dependency is like expecting Linux users to install some non-official packages just to be able to build. Especially in corporate environments that's not easy. Moreover the benefit would be really minimal, because the Xrandr functionality won't be available at runtime anyway. So to cut a long story short, I see two options: 1. Go with my current patch (ugly but efficient) 2. Check-in in an AIX specific version of XRander.h/randr.h under src/java.desktop/aix (OK for me, but that would actually negate the initial purpose of "8210863: Remove Xrandr include files") Do you have a better proposal? Thank you and best regards, Volker On Fri, Nov 16, 2018 at 11:22 AM Volker Simonis <volker.simonis(a)gmail.com> wrote: > > On Thu, Nov 15, 2018 at 6:01 PM Philip Race <philip.race(a)oracle.com> wrote: > > > > PS I am not sure why xrandr headers would not be available for AIX. > > They are a standard part of the xdistribution. > > > > I'm not an X11 guru, but as far as I understand, xrandr is an > extension and as such it doesn't have to be supported by every > implementation. To the best of my knowledge (I've just started another > poll among some experts) AIX doesn't support Xrandr and does not have > the corresponding headers. > > > If true, think what you are going to have to do is add a > > --with-xrandr-include option > > and provide it that way. > > > > What if there are no standard Xrandr headers on a platform? Do you > really want to force users to get them from some dubious sources just > for building the OpenJDK? Sorry, but I don't think that's a good > solution. Than I'd rather prefer the ugly ifdefs (or I check the > headers back in again in an AIX-specific directory :) > > Thank you and best regards, > Volker > > > -phil. > > > > On 11/15/18, 8:55 AM, Philip Race wrote: > > > Hmm. I don't like the ifdefs. > > > > > > Xrandr is a requirement for the build. If its not there at runtime > > > that's OK. > > > > > > -phil. > > > > > > On 11/15/18, 8:06 AM, Volker Simonis wrote: > > >> Hi, > > >> > > >> can I please have a review for the following small change: > > >> > > >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8213944/ > > >> https://bugs.openjdk.java.net/browse/JDK-8213944 > > >> > > >> Change JDK-8210863 removed the Xrandr.h/randr.h headers from the > > >> OpenJDK sources but forgot to add a configure check for the Xrandr > > >> extension which is now a build dependency. > > >> > > >> The change also broke the AIX build. AIX never supported Xrandr, but > > >> that was only detected at runtime, when the JDK was unable to > > >> dynamically load libXrand.so. Now, without Xrandr.h/randr.h in the > > >> source tree any more, we have to conditionally compile some parts of > > >> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c such > > >> that it doesn't require the definitions and declarations from > > >> Xrandr.h/randr.h any more. > > >> > > >> Thank you and best regards, > > >> Volker

4 7

RE: RFR: 8214205: PPC64: Add instructions for counting trailing zeros
by Doerr, Martin 23 Nov '18

23 Nov '18

Hi Michihiro, this change needs to get reviewed on hotspot-compiler-dev (added). Also added missing "RFR". The change looks good. I only have very minor requests: "_Ex" should be removed from the new instruct names. They aren't expand rules. Please also update the copyright year in the header of the ad file. Maybe Gustavo can test it, write a 2nd review and push it when it's good. Best regards, Martin From: Michihiro Horie <HORIE(a)jp.ibm.com> Sent: Donnerstag, 22. November 2018 06:40 To: ppc-aix-port-dev(a)openjdk.java.net Cc: Gustavo Romero <gromero(a)linux.vnet.ibm.com>; Doerr, Martin <martin.doerr(a)sap.com> Subject: RFR: 8214205: PPC64: Add instructions for counting trailing zeros Dear all, Would you please review the following change that enables POWER9's instructions for counting trailing zeros? Bug: https://bugs.openjdk.java.net/browse/JDK-8214205 Webrev: http://cr.openjdk.java.net/~mhorie/8214205/webrev.00/ Simple micro benchmark attached showed improvements by around 30%. (See attached file: CNTTZTest.java) Currently, Gustavo@IBM can test POWER9 specific changes. (Thanks Gustavo!) Best regards, -- Michihiro, IBM Research - Tokyo

3 3