- s390x-port-dev - openjdk.org

New lead for the s390x Port Project: Amit Kumar
by Dalibor Topic 10 May '24

10 May '24

Hi, Volker Simonis has resigned as lead for the s390x Port Project [1]. Under the bylaws for Project Roles [2], a new Project Lead may be nominated by the Group Leads of the Project's sponsoring groups. The Porters Group is sponsor of the project. As Group Lead, I would like to nominate Amit Kumar as the new Project Lead. As the Porters Group is the only sponsoring group for this project, the nomination is automatically approved. Thank you for your contributions as Project Lead, Volker, and all the best in the new role, Amit. I will notify the Registrar of the change. cheers, dalibor topic [1] https://mail.openjdk.org/pipermail/s390x-port-dev/2024-May/000169.html [2] http://openjdk.java.net/bylaws#project-lead -- <http://www.oracle.com> Dalibor Topic Consulting Product Manager Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961 <tel:+491737185961> Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann

1 0

Resigning as s390x Port Project Lead
by Volker Simonis 06 May '24

06 May '24

I hereby resign as s390x Port Project Lead. The s390x port has been integrated into the mainline in JDK 9 [1] and is ever since supported there by SAP and recently IBM. Since then the s390x Project is responsible for maintaining the port (updates can be found in the the s390x Project Wiki [2]). According to the OpenJDK Bylaws, the Lead of the sponsoring group (Dalibor Topic from the Porters Group) needs to assign a new Project Lead [4]. I want to propose Amit Kumar (OpenJDK name amitkumar [3]) as new Project Lead. Amit is employed by IBM and actively working on the s390 maintenance and feature implementation. He recently became an OpenJDK Committer with a track record of 38 commits to the project [5]. Thank you and best regards, Volker [1] https://github.com/openjdk/jdk/commit/a4cfffae9b [2] https://wiki.openjdk.org/display/s390xPort [3] https://openjdk.org/census#amitkumar [4] http://openjdk.java.net/bylaws#project-lead [5] https://github.com/issues?page=1&q=is%3Apr+author%3Aoffamitkumar+archived%3…

2 1

Semeru JDK 17 issues on s390x
by Christian Beikov 23 Apr '24

23 Apr '24

Hi, we're regularly testing Hibernate ORM on s390x, but recently started experiencing issues when building Hibernate ORM 7.0 on s390x, since that requires JDK 17. You can find the error log here: https://ci.hibernate.org/job/hibernate-orm-pipeline/job/wip%2F7.0/20/execut… <https://ci.hibernate.org/job/hibernate-orm-pipeline/job/wip%2F7.0/20/execut…> We essentially run into a JVM error. We're using the latest available Semeru JDK 17: https://github.com/ibmruntimes/semeru17-binaries/releases/tag/jdk-17.0.10%2… <https://github.com/ibmruntimes/semeru17-binaries/releases/tag/jdk-17.0.10%2…> I hope this is the right place to report this. Can you maybe also suggest a workaround for the meantime? Regards, -- Christian Beikov He / Him / His Senior Software Engineer, PnT Red Hat <https://www.redhat.com> cbeikov(a)redhat.com <mailto:cbeikov@redhat.com> M: +43-660-255-2170 <tel:+43-660-255-2170> <https://www.redhat.com> Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany *Commercial register:* Amtsgericht München/Munich, HRB 153243, *Managing Directors:* Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

2 2

SAP terminates linux s390 support
by Lindenmaier, Goetz 19 Jul '21

19 Jul '21

Hi, SAP has contributed the s390 port[1][2] to OpenJDK 9 and maintained it through JDK 11 up to JDK 17. It is ready to be released with JDK 17. After release of jdk 17 and 11.0.12 SAP will end its active support of this platform. We will no more maintain, build and test OpenJDK 11u, 17u or jdk and resign from the OpenJDK s390x Port Project. IBM will step in and continue to support the project. Best regards, Goetz. [1] https://wiki.openjdk.java.net/display/s390xPort [2] http://openjdk.java.net/projects/s390x-port/

2 1

Re: RFR(XS): 8230552: Provide information when hitting a HaltNode for architectures other than x86
by Volker Simonis 30 Apr '20

30 Apr '20

Forwarding to ppc-aix and s390 port mailing lists with the kind request for testing this simple fix on the corresponding platforms. Thank you and best regards, Volker Liu, Xin <xxinliu(a)amazon.com> schrieb am Do., 30. Apr. 2020, 08:39: > > > On 4/29/20, 11:06 PM, "Pengfei Li" <Pengfei.Li(a)arm.com> wrote: > > > > Hi Xin, > > > I tested on aarch64. It generates the same crash report as x86_64 > when it > > does hit HaltNode. Halt reason is displayed. I paste report on the > JBS. > > I ran hotspot:tier1 on aarch64 fastdebug build. It passed except > for 3 > > relevant failures[1]. > > (NOT a reviewer) The original instruction used should be dcps1 instead > of dpcs1 - there's a misspelling in AArch64 assembler. Could you add a > trivial fix to change dpcs1/2/3 to dcps1/2/3? > > Oh, I don't know that. I did search dpcs and found nothing. > I've filed a new issue about the typo thing: JDK-8244170. Let's resolve > it in separated issue. > > BTW, how did you test to hit the HaltNode? > -- > Thanks, > Pengfei > > I followed Christian and Volkers' recipe on JDK-8230552. Both of them can > generate HaltNode. > Volker's approach is very interesting. You have to give program a couple > of "-XX:SuppressErrorAt=" to increase tolerance. > > Thanks, > --lx > > >

1 0

Open ppc/s390/aix issues
by Lindenmaier, Goetz 09 Jan '19

09 Jan '19

Hi, We are now working on the ppc/s390/aix ports for quite some years. With the release of jdk11 we delivered a very comprehensive and well maintained port I think. For example, the jdk and hotspot jtreg tests can be run quite stable on these platforms. I filed bugs for all the remaining issues we see, at least in the test setup we run at SAP. Everybody is invited to join in and fix these few finally :) 8207404: MulticastSocket tests failing on Aix https://bugs.openjdk.java.net/browse/JDK-8207404 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX https://bugs.openjdk.java.net/browse/JDK-8030957 8211769: Port Dtrace support to ppc. https://bugs.openjdk.java.net/browse/JDK-8211769 8211771: Port Dtrace support to s390x. https://bugs.openjdk.java.net/browse/JDK-8211771 8211767: jtreg: Some SA tests are failing on PPC64 https://bugs.openjdk.java.net/browse/JDK-8211767 8211844: [aix] ProcessBuilder: Piping between created processes does not work. https://bugs.openjdk.java.net/browse/JDK-8211844 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected" https://bugs.openjdk.java.net/browse/JDK-8211847 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fais: read times out https://bugs.openjdk.java.net/browse/JDK-8211854 8211851: /java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix) https://bugs.openjdk.java.net/browse/JDK-8211851 8211841: [aix] sun/nio/cs/OLD/TestIBMDB.java fails with compilation error https://bugs.openjdk.java.net/browse/JDK-8211841 Best regards, Goetz.

3 6

RFR(S): 8213436: Obsolete UseMembar
by Mikael Vidstedt 08 Nov '18

08 Nov '18

Please review this change which obsoletes the UseMembar flag and removes the code that then becomes unreachable/dead. bug: https://bugs.openjdk.java.net/browse/JDK-8213436 <https://bugs.openjdk.java.net/browse/JDK-8213436> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/> * Background (from jbs) The UseMembar flag was deprecated in JDK 10, and is default true/enabled on all platforms since that same release. It should be obsoleted and the then dead serialization page functionality it controls should be removed. * Testing tier1. If anybody wants to take it for a spin on aarch64/ppc/s390/x86_32 that wouldn’t hurt. (Unrelated to this change: It would be really nice to clean up some of the (mostly) duplicated code in the os/signal handling area...) Cheers, Mikael

5 7

RFR(S): 8210676: Remove some unused Label variables
by Mikael Vidstedt 14 Sep '18

14 Sep '18

Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! bug: https://bugs.openjdk.java.net/browse/JDK-8210676 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ * Background (from bug) [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. * About the change I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I’m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. * Testing tier1 build&test passes. Cheers, Mikael

5 6

RFR(S): 8210381: Obsolete EmitSync
by Mikael Vidstedt 07 Sep '18

07 Sep '18

Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 <https://bugs.openjdk.java.net/browse/JDK-8210381> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/> * Background (from bug) The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. Cheers, Mikael

5 8

RE: [CAUTION] RE: RFR JDK-8209786: gcc 7.3 compiler errors
by Lindenmaier, Goetz 24 Aug '18

24 Aug '18

Hi, maybe use -1LL or 0xfff...ULL ... But please, this is still not the right list to discuss this. Best regards, Goetz. > -----Original Message----- > From: Keith Campbell <keithc(a)ca.ibm.com> > Sent: Donnerstag, 23. August 2018 15:04 > To: Andrew Leonard <andrew_m_leonard(a)uk.ibm.com> > Cc: Lindenmaier, Goetz <goetz.lindenmaier(a)sap.com>; > joe.darcy(a)oracle.com; Schmidt, Lutz <lutz.schmidt(a)sap.com>; s390x-port- > dev(a)openjdk.java.net > Subject: Re: [CAUTION] RE: RFR JDK-8209786: gcc 7.3 compiler errors > > I agree, -(1>>3) isn't what we want, but leaving it as it was isn't guaranteed to > yield the desired result. > > Instead, I suggest the right shifts should be applied to unsigned values: > - mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); > + mlib_u64 emask = ((mlib_u64)(-1)) >> ((8 - (size - i)) * 8) > > -Keith > > > ----- Original message ----- > From: Andrew Leonard/UK/IBM > To: "Schmidt, Lutz" <lutz.schmidt(a)sap.com>, joe.darcy(a)oracle.com > Cc: "Lindenmaier, Goetz" <goetz.lindenmaier(a)sap.com>, "s390x- > port-dev(a)openjdk.java.net" <s390x-port-dev(a)openjdk.java.net>, Keith > Campbell/Ottawa/IBM@IBMCA > Subject: Re: [CAUTION] RE: RFR JDK-8209786: gcc 7.3 compiler errors > Date: Thu, Aug 23, 2018 4:05 AM > > Thanks for the reviews guys, > Lutz, yes, those "undefined" behaviour's is what gcc7.3 is now > highlighting, and we're trying to fix. > > Goetz, I see what you're saying, I think we should leave the right > shifts alone then, although as stated in Lutz's doc reference they are > implementation-defined, I think the original code is trying to achieve the > former 000111...111, I doubt it was trying to achieve 0! > before, -1 >> 3 will result in something like 000111...111 > now -(1>>3) will result in 000....0000 > > It is the left shirt of -ve values that is the real concern. > > Joe, also suggested we should tackle this by changing the compiler > options rather than changing libfdlibm, which maybe the alternative as this > source has not changed for a long time and maybe best to let working code > remain unchanged, i'd have to investigate a compiler option fix... > > Keith, do you have any other views? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard(a)uk.ibm.com > > > "Schmidt, Lutz" ---22/08/2018 16:50:27---Hi Andrew, just recently I > was confronted with a similar "shift issue" which prompted me to read th > > From: "Schmidt, Lutz" <lutz.schmidt(a)sap.com> > To: "Lindenmaier, Goetz" <goetz.lindenmaier(a)sap.com>, Andrew > Leonard <andrew_m_leonard(a)uk.ibm.com>, "s390x-port- > dev(a)openjdk.java.net" <s390x-port-dev(a)openjdk.java.net> > Date: 22/08/2018 16:50 > Subject: Re: [CAUTION] RE: RFR JDK-8209786: gcc 7.3 compiler errors > ________________________________ > > > > > Hi Andrew, > just recently I was confronted with a similar "shift issue" which > prompted me to read the language standard (again). I have summarized my > understanding in a little text file which you may find attached. Have fun > reading! > Best Regards, > Lutz > > On 22.08.18, 09:18, "s390x-port-dev on behalf of Lindenmaier, Goetz" > <s390x-port-dev-bounces(a)openjdk.java.net on behalf of > goetz.lindenmaier(a)sap.com> wrote: > > Hi Andrew, > > please post this RFR to core-libs-dev. > > s390x-prot-dev is only for questions about the port etc. > It is not for reviews that go to jdk/jdk. > > Also, I'm not sure that your change in java.desktop is correct. > You now negate after shifting. > > - mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * > 8); > + mlib_u64 emask = (mlib_u64)-(((mlib_s64)1) >> ((8 - (size - i)) * > 8)); > > before, -1 >> 3 will result in something like 000111...111 > now -(1>>3) will result in 000....0000 > > Best regards, > Goetz. > > > > > > > > > > -----Original Message----- > > From: s390x-port-dev <s390x-port-dev- > bounces(a)openjdk.java.net> On > > Behalf Of Andrew Leonard > > Sent: Dienstag, 21. August 2018 15:05 > > To: s390x-port-dev(a)openjdk.java.net > > Subject: RFR JDK-8209786: gcc 7.3 compiler errors > > > > Hi, > > We have discovered issues with gcc 7.3 on zLinux, combined with > OpenJDK's > > default compiler options has highlighted a couple of native code > issues, > > with: > > - validating loop test array bounds > > - left shifts of negative values > > I have created bug https://bugs.openjdk.java.net/browse/JDK- > 8209786 > > and attached the webrev fix here: > > http://cr.openjdk.java.net/~aleonard/gcc73/webrev.00/ > > > > I'd like to request a sponsor for this fix please? > > > > Many thanks > > Andrew > > > > Andrew Leonard > > Java Runtimes Development > > IBM Hursley > > IBM United Kingdom Ltd > > Phone internal: 245913, external: 01962 815913 > > internet email: andrew_m_leonard(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 > > > [attachment "cppShiftOperations.txt" deleted by Andrew > Leonard/UK/IBM] > >

1 0