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

RFR(S): 8196487: AIX: os::get_summary_cpu_info does not need to call into libperfstat
by Langer, Christoph 31 Jan '18

31 Jan '18

Hi, please review an AIX only change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196487.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196487 The implementation of os::get_summary_cpu_info() on AIX currently calls libperfstat::get_cpuinfo() which in turn only fills the version field of struct cpuinfo_t for the purpose of os::get_summary_cpu_info. This should be decoupled. Thanks & Best regards Christoph

3 4

RFR : PPC64 : Need support for VSR spills in ppc.ad
by Michihiro Horie 24 Jan '18

24 Jan '18

Hi Martin, Would you review the following change that fixes the SLP for PPC? In this change, I added support for VSR spills. Also, I fixed how to specify registers in postalloc_expand for the float constant replication. I confirmed this change works with JTREG. Bug: https://bugs.openjdk.java.net/browse/JDK-8194861 webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.00/ (I created a webrev under jdk/hs.) Best regards, -- Michihiro, IBM Research - Tokyo

4 18

RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad
by Baesken, Matthias 03 Jan '18

03 Jan '18

Hello , Mark reported this issue on AIX with OpenJDK8 : > >I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is: > > java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D > getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2 > <init> at org/logstash/instrument/monitors/ProcessMonitor.java:40 > detect at org/logstash/instrument/monitors/ProcessMonitor.java:79 > generate at org/logstash/instrument/reports/ProcessReport.java:15 > > this is the line in logstash: > > this.cpuProcessPercent = scaleLoadToPercent(unixOsBean.getProcessCpuLoad()); > > https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java… > > > Could anybody help steer me in the right direction? > This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX . JDK8 is only affected , JDK9 and higher is not affected . Could I get a review for this change ? Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/ Bug : https://bugs.openjdk.java.net/browse/JDK-8193807 Thanks, Matthias

4 7

java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()
by Evans, Martin 14 Dec '17

14 Dec '17

Hi, I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is: java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2 <init> at org/logstash/instrument/monitors/ProcessMonitor.java:40 detect at org/logstash/instrument/monitors/ProcessMonitor.java:79 generate at org/logstash/instrument/reports/ProcessReport.java:15 this is the line in logstash: this.cpuProcessPercent = scaleLoadToPercent(unixOsBean.getProcessCpuLoad()); https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java… Could anybody help steer me in the right direction? Thanks Martin ------------ Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, London W2 6PX Registered in England, Number 1664812 This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of the company. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person. Thank you for your co-operation.

4 5

RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces
by Volker Simonis 28 Nov '17

28 Nov '17

Hi, can I please have a review for the following small, ppc64-only change which fixes CDS on Power: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ https://bugs.openjdk.java.net/browse/JDK-8191770 Don't rewrite invokefinal into fast_invokevfinal if running with DumpSharedSpaces or UseSharedSpaces. The Template-Interpreter of the ppc-Port was initially derived from the SPARC version which didn't had full CDS support at that time, that's why the guard against DumpSharedSpaces was missing at the place where invokefinal is rewritten. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/ppc64, Linux/ppc64le and AIX. Thank you and best regards, Volker

3 4

Re: Cross compile jdk8u on PPC32
by Tiago Daitx 15 Nov '17

15 Nov '17

Thanks for the input Andrew, good to know it makes the powerpc build non Java compatible (I assume this means JCK, right? I never ran it for non-intel systems) That particular patch has been added to Debian's OpenJDK 7 back in 2013, which was then carried over to OpenJDK 8 as well. It was based on this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712686 If anyone has a better fix, I would be glad to replace the patch - or remove it altogether if it makes upstream to OpenJDK 7 and 8. ;-) Regards, Tiago On Fri, Nov 10, 2017 at 12:22 PM, Andrew Haley <aph(a)redhat.com> wrote: > On 02/11/17 00:11, Tiago Daitx wrote: >> Please check if this patch from Debian/Ubuntu fix your issue: >> http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/view/head:/debian/pat… > > That looks wrong to me. You need a real way to copy 64-bit items atomically > or you won't be Java compatible. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Tiago Stürmer Daitx Software Engineer tiago.daitx(a)canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE

2 1

RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs
by dean.long＠oracle.com 13 Nov '17

13 Nov '17

https://bugs.openjdk.java.net/browse/JDK-8190817 http://cr.openjdk.java.net/~dlong/8190817/webrev/ This fix replaces the problematic use of _normal_table.entry(Bytecodes::_return).entry(vtos) as a deoptimization entry point with a proper deopt entry point returned by deopt_reexecute_return_entry(). This is needed to handle the situation where compiled code is calling register_finalizer() and gets deoptimized. I also noticed that we generate duplicate entry points unnecessarily, so I cleaned that up at the same time. aarch64/ppc64/s390 folks, please check that compiler/runtime/Test8168712.java still passes. dl

1 0

Re: Cross compile jdk8u on PPC32
by Bob Vandette 10 Nov '17

10 Nov '17

As others have mentioned, you need to target ZERO and not PPC32 when trying to build a non supported cpu architecture with the Zero interpreter. You do need to have a libffi.so binary available for the build. Zero uses this to manage the native stack frames. Bob. > On Oct 24, 2017, at 4:46 AM, Andrew Haley <aph(a)redhat.com> wrote: > > On 18/10/17 13:20, Radu Andritoiu wrote: >> I am trying to compile jdk8u using jvm-variant "zero" and it asks for >> 'libffi'. >> I read that it uses 'libffi' for JNA to bridge between the interpreter and >> native code. It does not use JNI. > > That's wrong. Zero supports JNI just fine. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

3 3

Re: Cross compile jdk8u on PPC32
by Radu Andritoiu 10 Nov '17

10 Nov '17

Hello, This fix didn't work for me. But the one in the next mail did work, I guess when cross-compiling it should not use specific ASM instructions. Thank you, Radu On Wed, Nov 1, 2017 at 8:21 PM, Andrew Haley <aph(a)redhat.com> wrote: > On 01/11/17 17:27, Radu Andritoiu wrote: > > > > I still have one error that I can not fix in order to compile the > "zero" jvm-variant for PPC32: > > - the error: > > > > Compiling /home/build/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp: > In static member function 'static jlong Atomic::add(jlong, volatile > jlong*)': > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > error: impossible constraint in 'asm' > > /home/build/jdk8u/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp:44: > error: impossible constraint in 'asm' > > gmake[6]: *** [atomic.o] Error 1 > > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >

1 0

RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image
by Baesken, Matthias 26 Oct '17

26 Oct '17

Hello , could you please review and push this small change fixing the aix jre generation in jdk10 : http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ (and later on it would be good to get it into jdk9 as well because the same issue exists there too) Thanks and best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie@oracle.com] > Sent: Mittwoch, 25. Oktober 2017 16:46 > To: Erik Joelsson <erik.joelsson(a)oracle.com>; Baesken, Matthias > <matthias.baesken(a)sap.com>; Thomas Stüfe <thomas.stuefe(a)gmail.com> > Cc: build-dev (build-dev(a)openjdk.java.net) <build-dev(a)openjdk.java.net>; > ppc-aix-port-dev(a)openjdk.java.net > Subject: Re: AIX build not generating a jre image > > On 2017-10-25 15:21, Erik Joelsson wrote: > > Ah, good find. I would argue that the correct fix is: > > > > jdk: $(TOOL_JDK_TARGETS) $(JDK_TARGETS) > > jre: $(TOOL_JRE_TARGETS) $(JRE_TARGETS) > > Yeah, good find Matthias! > > I agree with Erik's suggested fix. This is a bit of "how has this ever > worked?!?". It turns out that our closed extensions are unconditionally > adding targets to JRE_TARGETS, so we never noticed that it could happen > that JRE_TARGETS are empty, and the building of the JRE image does not > work. This will happen on Windows as well as AIX. > > /Magnus > > > > > /Erik > > > > On 2017-10-25 14:57, Baesken, Matthias wrote: > >> Hi Magnus, thanks for your advice. > >> Adding a bit of tracing to Images.gmk indeed helps to clarify the > >> issue . > >> Output of $(info this is the jre location: > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) looks nice and as > expected > >> on AIX . > >> However it turns out the $(JRE_TARGETS) was empty on AIX , > >> this leads to an empty dependency > >> > >> jre: $(JRE_TARGETS) > >> > >> on AIX in Images.gmk , and this leads to “Nothing to be done for …. “. > >> Background is that aix was not considered in the platform > >> dependent parts of make/Images.gmk where JRE_TARGETS is filled > >> for linux, macosx, solaris. > >> I added aix there and the jre shows up in the images. > >> Here is my diff (openjdk9) , still with tracing output AND with > >> the added aix . > >> Now JRE_TARGETS is not empty anymore which leads to successful > >> generation of the JRE. > >> > >> Tracing output seen in the makefile > >> + echo JRE_TARGETS are: > /mygenerationdir/images/jre/man/man1/java.1 …. > >> > >> > >> Diff with tracing : > >> > >> diff -r a08cbfc0e4ec make/Images.gmk > >> --- a/make/Images.gmk Thu Aug 03 18:56:56 2017 +0000 > >> +++ b/make/Images.gmk Wed Oct 25 14:41:06 2017 +0200 > >> @@ -43,6 +43,10 @@ > >> $(eval $(call ReadImportMetaData)) > >> +# helpful tracing > >> +$(info this is the jre location: > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > >> + > >> + > >> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ > >> $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) > >> JDK_MODULES += $(ALL_MODULES) > >> @@ -295,7 +299,7 @@ > >> $(addprefix $(JDK_IMAGE_DIR)/man/ja_JP.PCK/man1/, > >> $(JDK_MAN_PAGES)) > >> endif > >> - ifneq ($(findstring $(OPENJDK_TARGET_OS), linux macosx), ) > >> + ifneq ($(findstring $(OPENJDK_TARGET_OS), aix linux macosx), ) > >> JRE_MAN_PAGE_LIST = $(addprefix $(JRE_IMAGE_DIR)/man/man1/, > >> $(JRE_MAN_PAGES)) \ > >> $(addprefix $(JRE_IMAGE_DIR)/man/ja_JP.UTF-8/man1/, > >> $(JRE_MAN_PAGES)) \ > >> $(JRE_IMAGE_DIR)/man/ja > >> @@ -436,6 +440,8 @@ > >> jdk: $(JDK_TARGETS) > >> jre: $(JRE_TARGETS) > >> + echo JRE_TARGETS are: $(JRE_TARGETS) , TOOL_JRE_TARGETS are: > >> $(TOOL_JRE_TARGETS) > >> + > >> symbols: $(SYMBOLS_TARGETS) > >> > >> > >> Best regards, Matthias > >> > >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie@oracle.com] > >> Sent: Mittwoch, 25. Oktober 2017 10:24 > >> To: Baesken, Matthias <matthias.baesken(a)sap.com>; Thomas Stüfe > >> <thomas.stuefe(a)gmail.com> > >> Cc: build-dev (build-dev(a)openjdk.java.net) > >> <build-dev(a)openjdk.java.net>; ppc-aix-port-dev(a)openjdk.java.net > >> Subject: Re: AIX build not generating a jre image > >> > >> > >> On 2017-10-24 16:44, Baesken, Matthias wrote: > >> > >> * Do you get to this stage at all? I.e, can you see "Createing > >> jre jimage" in the output? > >> > >> Hi Magnus, when comparing the linux and aix logs of our openjdk9 > >> builds , I see for Linux at some point : > >> > >> > >> > >> gmake[3]: Entering directory ` . . . /nightly/jdk9/make' > >> > >> /bin/echo Creating jre jimage > >> > >> > >> While on AIX it says : > >> > >> > >> make[3]: Entering directory ` . . . /nightly/jdk9/make' > >> > >> make[3]: Nothing to be done for `jre'. > >> > >> make[3]: Leaving directory ` . . . /nightly/jdk9/make' > >> > >> > >> this Looks wrong to me ! > >> That means that $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is > considered > >> up to date by make. This is wrong if that file does not exist. Are > >> you *sure* you do not have a jre built? > >> Verify the contents of these variables. Perhaps add a > >> $(info this is the jre location: > $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE)) > >> at the top of Images.gmk, > >> and check the location that is printed. > >> > >> /Magnus > >> > >> > >> > >> > >> ( the . . . in the output has been removed by me it points to > >> the build dir). > >> > >> Best regards, Matthias > >> > >> > >> From: ppc-aix-port-dev > >> [mailto:ppc-aix-port-dev-bounces@openjdk.java.net] On Behalf Of > >> Magnus Ihse Bursie > >> Sent: Dienstag, 24. Oktober 2017 15:47 > >> To: Thomas Stüfe > >> <thomas.stuefe(a)gmail.com><mailto:thomas.stuefe@gmail.com> > >> Cc: build-dev > >> (build-dev(a)openjdk.java.net<mailto:build-dev@openjdk.java.net>) > >> <build-dev(a)openjdk.java.net><mailto:build-dev@openjdk.java.net>; > >> ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port- > dev(a)openjdk.java.net> > >> > >> Subject: Re: AIX build not generating a jre image > >> > >> On 2017-10-23 10:16, Thomas Stüfe wrote: > >> Hi Magnus, > >> > >> On Mon, Oct 23, 2017 at 9:12 AM, Magnus Ihse Bursie > >> > <magnus.ihse.bursie(a)oracle.com<mailto:magnus.ihse.bursie@oracle.com> > > > >> wrote: > >> > >> On 2017-10-18 16:14, Thomas Stüfe wrote: > >> On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis > >> <volker.simonis(a)gmail.com<mailto:volker.simonis@gmail.com>> > >> wrote: > >> Hi Goetz, > >> > >> How do our nightly builds look like? Do they create the JRE image? > >> > >> Regards, > >> Volker > >> > >> > >> Goetz is in a meeting. > >> > >> None of our AIX builds creates a JRE image. Works on other platforms. > >> Looks > >> like a bug. > >> > >> I tried to build jre explicitly (make jre-image); build finishes > >> sucessfully but still no jre. > >> Since I don't have access to any AIX machines, it's difficult to for > >> me to do much about this. Let me know if you need assistance in > >> tracking this down. > >> > >> Some suggestions: > >> run "make LOG=info,cmdlines" to track the progress of the build. > >> > >> If you get lost in the log files, try running "make jre-image" and > >> then "rm build/$BUILD/images/jre", and then "make LOG=info,cmdlines > >> jre-image" to see only the output for the jre-image target. > >> > >> Thanks for the hints! I'll try that. I played around last week with > >> make -d --print-data-base but got lost in the information. > >> > >> Last week I burned some time on this problem without much success. I > >> got stuck understanding the rule in Images.gmk: > >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE): $(JMODS) \ > >> $(call DependOnVariable, JRE_MODULES_LIST) $(BASE_RELEASE_FILE) > >> $(ECHO) Creating jre jimage > >> $(RM) -r $(JRE_IMAGE_DIR) > >> $(JLINK_JRE_EXTRA_OPTS) \ > >> $(JLINK_TOOL) --add-modules $(JRE_MODULES_LIST) \ > >> --output $(JRE_IMAGE_DIR) > >> $(TOUCH) $@ > >> > >> and its brethren. > >> > >> It seems this rule just does not get executed for jre-image. So, > >> trying to understand this (I am no makefile expert): > >> > >> $(JRE_IMAGE_DIR)/$(JIMAGE_TARGET_FILE) is one file from the target > >> dir, in this case jre/java, whose non-existence or out-of-dateness > >> triggers the rule > >> > >> Dependencies: > >> - $(JMODS) is <outputdir>/jmods, which gets built and does exist > >> - $(call DependOnVariable, JRE_MODULES_LIST) > >> This is just a macro that creates a dependency on the contents of the > >> variable JRE_MODULES_LIST. > >> > >> > >> > >> $(BASE_RELEASE_FILE) is a text file which, if it exists and it > >> contains the value of $JRE_MODULES_LIST, will result false (not out > >> of date), otherwise it will update the file with the value of > >> $JRE_MODULES_LIST and return true, triggering the target, yes? If I > >> got this right, why do we use the same output file for all targets > >> (jre, jdk) etc? > >> No, this is a separate dependency. It's the file named "release" in > >> the image that is to be included. If it has changed we need to > >> trigger a new image. > >> > >> Do you get to this stage at all? I.e, can you see "Createing jre > >> jimage" in the output? If not, there's a problem before we even get > >> to this rule. Otherwise, the jlink command is likely broken. Try > >> copy-pasting the full jlink command and running it from the shell > >> directly to see what happens. > >> > >> /Magnus > >> > >> > >> > >> ..Thomas > >> > >> > >> > >> /Magnus > >> > >> > >> > >> > >> I created https://bugs.openjdk.java.net/browse/JDK-8189618 to track > >> this. > >> > >> ..Thomas > >> > >> > >> > >> > >> Lindenmaier, Goetz > >> <goetz.lindenmaier(a)sap.com<mailto:goetz.lindenmaier@sap.com>> > schrieb > >> am Mi. 18. Okt. > >> 2017 > >> um 14:56: > >> Hi Steve, > >> > >> I think this is an error. > >> We never decided not to generate a jre image as far as I know. > >> > >> Best regards, > >> Goetz. > >> -----Original Message----- > >> From: ppc-aix-port-dev > >> [mailto:ppc-aix-port-dev-<mailto:ppc-aix-port-dev-> > >> bounces(a)openjdk.java.net<mailto:bounces@openjdk.java.net>] On > Behalf > >> Of Steve Groeger > >> Sent: Mittwoch, 18. Oktober 2017 14:34 > >> To: > >> ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port- > dev(a)openjdk.java.net> > >> Subject: AIX build not generating a jre image > >> > >> Hi all, > >> > >> When building OpenJDK9 on AIX should the build generate a JRE image ie > >> build/aix-ppc64-normal-server-release/images/jre/bin as well as a JDK > >> image > >> ie build/aix-ppc64-normal-server-release/images/jdk/bin? When I try > >> building on my AIX system it is only generating a JDK image. Is this a > >> issue or is > >> it working correctly? > >> > >> > >> Thanks > >> Steve Groeger > >> Java Runtimes Development > >> IBM Hursley > >> IBM United Kingdom Ltd > >> 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<mailto:groeges@uk.ibm.com> > >> <mailto:groeges@uk.ibm.com<mailto:groeges@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 3