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

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
by Volker Simonis 04 Oct '18

04 Oct '18

Hi Tim, Jeff, Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) https://bugs.openjdk.java.net/browse/JDK-8208089 Could you please provide a summary of which of these features are already available since which version of xlC for AIX and potentially escalate the implementation of the missing features within IBM’s xlC on AIX team. Thank you and best regards, Volker Kim Barrett <kim.barrett(a)oracle.com> schrieb am Mi. 3. Okt. 2018 um 22:13: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > >

2 1

[8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling
by Severin Gehwolf 04 Oct '18

04 Oct '18

Hi, Could I please get reviews for this JDK 8 backport which fixes some tooling issues on Linux ppc64le? Prior this patch, a ppc64le build would report as "ppc64" via os.arch system property which breaks tooling such as maven in as much as if some dependency needs native libraries it would download BE binaries where it actually should download LE binaries. Example for os.arch/java.library.path: pre: $ ./jdk8-pre-ppc64le/bin/java TestProperty java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib os.arch = ppc64 post: $ ./jdk8-post-ppc64le/bin/java TestProperty java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib os.arch = ppc64le Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev for JDK/hotspot changes. This backport should only have minor differences to the changes in JDK 11. We have been using similar patches in Fedora for months. Thoughts? Thanks, Severin

4 14

Re: [8u] RFR for backport of JDK-8164920: ppc: enhancement of CRC32 intrinsic to jdk8u-dev (v2)
by Gustavo Romero 02 Oct '18

02 Oct '18

Hi, Maybe I please get reviews for the following changes (v2)? http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8131048/ http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8164920/ Change JDK-8131048 is a dependency to backport JDK-8164920 to 8u. Goetz reviewed the first version of this backport and pointed out necessary changes and fixes that are present in this v2. Thank you, Goetz. There is no code change except to adapt the file paths, to add has_vpmsumb() feature detection, and to adapt the signature before doing the runtime call to CRC32 intrinsic by casting T_INTs as T_LONGs, because PPC64 c_calling_convention() requires T_LONGs on 8u, otherwise a proper assert() for that is hit. Change JDK-8131048 touches shared code but, since it checks for 'CCallingConventionRequiresIntsAsLongs' flag that is only currently set on PPC64, that change is in effect PPC64-only. JDK-8164920 is important for PPC64 because it helps a lot some Apache Cassandra workloads on Power. Thank you. Best regards, Gustavo

2 2

RE: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX
by Langer, Christoph 21 Sep '18

21 Sep '18

Hi Matthias, this change looks good, helpful additions. Best regards Christoph > -----Original Message----- > From: hotspot-dev <hotspot-dev-bounces(a)openjdk.java.net> On Behalf Of > Baesken, Matthias > Sent: Donnerstag, 20. September 2018 14:13 > To: 'hotspot-dev(a)openjdk.java.net' <hotspot-dev(a)openjdk.java.net> > Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables > reported in error log file on AIX > > Hello, Please review this small enhancement. > > It adds these AIX-related environment variables to the already existing list > of environment variables that should be reported in error log file (hs_err file) > : > > LIBPATH : environment variable to locate shared libraries , see > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ib > m.java.aix.71.doc/user/setlpath.html > > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > aix.performance/preloading_shared_libraries.htm > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ > > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 > > > Thanks, Matthias

1 0

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

4 5

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
by Gustavo Romero 12 Sep '18

12 Sep '18

Hi Severin, On 09/11/2018 09:02 AM, Severin Gehwolf wrote: > Micro-benchmark results from running [1] for x86_64 and ppc64le are > here (-O2 is sufficient it seems): > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_re… > > More thoughts? Thanks a lot for checking it on PPC64. I did additional tests on a POWER8 using the same microbench. I share the results below. The numbers are the arithmetic mean of 10 runs. Unit is second. 1 O3 | O2 2 Math StrictMath | Math StrictMath 3 | 4 acos: 3.0728 3.0728 | acos: 3.07325 3.07375 5 asin: 3.0933 3.0916 | asin: 3.09337 3.0915 6 atan2: 10.9743 10.9759 | atan2: 11.2994 11.2977 7 atan: 7.653 7.6602 | atan: 7.48463 7.48225 8 cbrt: 13.444 13.4433 | cbrt: 13.4535 13.4527 9 cos: 30.1561 33.9689 | cos: 30.157 35.1162 10 cosh: 3.0911 3.1074 | cosh: 3.09975 3.09088 11 exp: 1.413 3.0572 | exp: 1.41313 3.09737 12 expm1: 3.0281 3.0349 | expm1: 2.98813 2.98913 13 hypot: 33.7668 33.7471 | hypot: 27.9664 27.9675 14 log10: 4.2213 10.0832 | log10: 4.221 10.1109 15 log1p: 9.2886 9.2888 | log1p: 9.08713 9.08075 16 log: 3.1362 7.6327 | log: 3.136 7.633 17 pow: 13.7787 17.4739 | pow: 13.7829 17.483 18 sin: 30.216 33.9733 | sin: 30.2163 35.1684 19 sinh: 3.1478 3.152 | sinh: 3.18638 3.18375 20 sqrt: 0.665 0.6714 | sqrt: 0.665 0.671 21 tan: 31.6409 36.461 | tan: 31.6385 37.7166 22 tanh: 3.0753 3.0925 | tanh: 3.11088 3.10675 Based upon that, it looks like that O3 is better for most of the functions, specially for sin, cos, and tan. On the other hand, it looks like that O3 hurts hypot. Thus it seems -O2 is not quite the same as -O3, but it's not straightforward to decide which one is better too. Maybe Andrew can enlight us. I also CC:ed ppc-aix-port in case somebody there wishes to comment on that. Thank you. Best regards, Gustavo > Thanks, > Severin > > [1] https://github.com/gromero/strictmath/ >

1 1

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

RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code
by Gustavo Romero 04 Sep '18

04 Sep '18

Hi, May I please request reviews for this tiny change that fixes two uninitialized variables in PPC64 C1 LIR code? Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ GCC 4.8 does not complain about these two uninitialized pointers ('data' and 'md') but more recent versions, like 5.4.0 and 7.3.1, complain about it: In file included from /home/gromero/hg/jdk/jdk/src/hotspot/share/c1/c1_Compilation.hpp:29:0, from /home/gromero/hg/jdk/jdk/src/hotspot/share/precompiled/precompiled.hpp:286: /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp: In member function ‘void LIR_Assembler::emit_typecheck_helper(LIR_OpTypeCheck*, Label*, Label*, Label*)’: /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp:595:100: warning: ‘data’ may be used uninitialized in this function [-Wmaybe-uninitialized] int byte_offset_of_slot(ciProfileData* data, ByteSize slot_offset_in_data) { return in_bytes(offset_of_slot(data, slot_offset_in_data)); } ^ /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2400:18: note: ‘data’ was declared here ciProfileData* data; ^ /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2483:78: warning: ‘md’ may be used uninitialized in this function [-Wmaybe-uninitialized] type_profile_helper(mdo, mdo_offset_bias, md, data, recv, Rtmp1, success); ^ Thank you. Best regards, Gustavo

4 9

RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type
by Thomas Stüfe 03 Sep '18

03 Sep '18

Hi all, may I please have reviews for this small, AIX-only change. cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does-not-show-sa… bug: https://bugs.openjdk.java.net/browse/JDK-8210314 On AIX, we have our own initialization for the safepoint mechanism. We missed registering the polling page with NMT, which the generic code path did. This patch adds that. Side note: We are different for two reasons. One, on ppc we use per default SIGTRAP for safepoint signalling, which can be switched off though. Second, on AIX, we cannot use os::reserve_memory() to obtain a polling page since that memory may not protectable (if it uses sysV shmat). Hence, the AIX specific coding. Best Regards, Thomas

4 6

RFR: 8208171: PPC64: Enrich SLP support
by Michihiro Horie 02 Sep '18

02 Sep '18

Dear all, Would you review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 This change adds support for vectorized arithmetic calculation with SLP. The to_vr function is added to convert VSR to VR. Currently, vecX is associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, which are exactly overlapped with VRs. Instruction APIs receiving VRs use the to_vr via vecX. Another thing is the change in sqrtF_reg to enable the matching with SqrtVF. I think the change in sqrtF_reg would be fine due to the ConvD2FNode::Value in convertnode.cpp. I confirmed this change with JTREG. In addition, I used attached micro benchmarks. (See attached file: slp_microbench.zip) Best regards, -- Michihiro, IBM Research - Tokyo

3 7