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

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

RFR(XS): 8151030: PPC64: AllocatePrefetchStyle=4 is out of range
by Doerr, Martin 27 Apr '20

27 Apr '20

Hi, I'd like to resolve a very old PPC64 issue: https://bugs.openjdk.java.net/browse/JDK-8151030 There's code for AllocatePrefetchStyle=4 which is not an accepted option. It was used for a special experimental prefetch mode using dcbz instructions to combine prefetching and zeroing in the TLABs. However, this code was never contributed and there are no plans to work on it. So I'd like to simply remove this small part of it. In addition to that, AllocatePrefetchLines is currently set to 3 by default which doesn't make sense to me. PPC64 has an automatic prefetch engine and executing several prefetch instructions for succeeding cache lines doesn't seem to be beneficial at all. So I'm setting it to 1 by default. I couldn't observe regressions on Power7, Power8 and Power9. Webrev: http://cr.openjdk.java.net/~mdoerr/8151030_ppc_prefetch/webrev.00/ Please review. If somebody from IBM would like to check performance impact of changing the AllocatePrefetchLines + Distance, I'll be glad to receive feedback. Best regards, Martin

3 5

Re: RFR[S]:8241874 [PPC64] Improve performance of Long.reverseBytes() and Integer.reverseBytes() on Power9
by Michihiro Horie 21 Apr '20

21 Apr '20

Hi Corey, I’m not a reviewer, but I can run your benchmark in my local P9 node if you share it. Best regards, Michihiro ----- Original message ----- From: Corey Ashford <cjashfor(a)linux.ibm.com> Sent by: "hotspot-compiler-dev" <hotspot-compiler-dev-bounces(a)openjdk.java.net> To: hotspot-compiler-dev(a)openjdk.java.net Cc: Subject: [EXTERNAL] RFR[S]:8241874 [PPC64] Improve performance of Long.reverseBytes() and Integer.reverseBytes() on Power9 Date: Tue, Mar 31, 2020 7:52 AM Hello, This is my first OpenJDK patch for review. It increases the performance of byte reversal for Integer.reverseBytes() and Long.reverseBytes() on Power9 via its VSX xxbrw and xxbrd vector instructions. https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_… https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7E… I have tested on Power9 and see a 38%+ performance improvement on Long.reverseBytes() and 15%+ on Integer.reverseBytes(). (I add the + because the benchmark code has a fair amount of fixed overhead). Testing on Power8 reveals no regressions. I believe the patch itself is pretty self-explanatory. It adds definitions for four instructions that are needed to get the data in and out of the vector registers, and to perform the reversal operation, and it adds the instructs to use them. Also VM_Version::initialize() autodetects that the instructions are available, and warns for trying to set the UseVectorByteReverseInstructionsPPC64 flag on earlier Power processors that don't possess these PowerISA 3.0 instructions. Thanks to Michihiro Horie, Jose Ricardo Ziviani, and Gustav Romero for their help! Please review this patch. Thanks for your consideration, Corey Ashford

3 8

Re: Fix for test/jdk/tools/jpackage/share/JavaOptionsTest.java on Alpine Linux
by Mikael Vidstedt 22 Feb '20

22 Feb '20

Looping in the AIX folks for good luck. I sorta expected the “hack” of enabling that re-execution in the launcher would bite back at some point, but at the time it seemed like the simple thing to do. At the time I even went down the rabbit hole of exploring the option of merging libjava.so and libjvm.so, but not sure that’s really practical or in the end even solves the problem. Assuming 1. is the “Right Way(tm)”, why wouldn’t we do that? :) Sharing the code would of course be nice, but worst case some duplication may be the better option? Cheers, Mikael > On Feb 20, 2020, at 5:29 AM, Alexander Scherbatiy <alexander.scherbatiy(a)bell-sw.com> wrote: > > > Hello, > > Short description: > > JavaOptionsTest.java test creates a jar file with a simple Hello java class, packages it into a native app and calls it. > > JLI reexecutes the native app on Linux Alpine and because of this java options are doubled when passed to Hello application. > > The proposed fix adds java options only if the application arguments does not contain them: > > http://cr.openjdk.java.net/~alexsch/portola/tests/jpackage/webrev.01 > > > Detailed description: > > The native app first calls start_launcher() method from src/jdk.incubator.jpackage/share/native/libapplauncher/main.cpp file which uses Package::SetCommandLineArguments() to store provided arguments in FBootFields->FArgs field. Next it calls RunVM(). > > JavaVirtualMachine::launchVM() method stores both java options and arguments from FBootFields->FArgs into jvm args list and calls javaLibrary.JavaVMCreate() so the provided args are passed to the java application. > > This path is different on Alpine Linux which sets LD_LIBRARY_PATH and JLI decides to invoke start_launcher() one more time with the updated library path (see [1]). > > This time all java options are passed to start_launcher() method, they stored in FBootFields->FArgs and concatenated with java options passed to JavaVirtualMachine::launchVM() method. > > So jvm options are stored twice in case the launcher decides to reexec itself. > > Possible solutions: > > 1. The right way would be to detect that the JLI is reexecuted in the same way as it does JLI (see [2]). It has some complicated logic in ContainsLibJVM() method and the code needs to be shared between java.base and jdk.incubator.jpackage modules. > > 2. Using a static variable to check that the jpackage is executed the second time. It does not work because the jpackage is executed by as a new process by execve(). > > Here are two subsequent calls of execve() on Alpine Linux from strace log: > > ----- > > execve("./output/test/bin/test", ["./output/test/bin/test", "-Dparam2=test2"], 0x7fff98259778 /* 8 vars */) = 0 > > execve("/root/mount/repos/branch-portola-dev/jtreg/alpine/app/output/test/bin/test", ["./output/test/bin/test", "-Djava.library.path=/root/mount/"..., "-Djava.l > arch_prctl(ARCH_SET_FS, 0x7f42a0298d48) = 0 > > ----- > > Java options are passed to the second app call there jpackage adds them one more time. > > > 3. Check in some way that the app arguments already contain java options and to not add them the second time. > > The proposed fix converts the app arguments to std::set. I tried to use std::unordered_set but got the error message: > > "#error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options." > > Actually java options are always set first for vmargs so it is also possible only to check that if the app arguments list starts with java options list. It relies on the way how java options are passed to jpackage and it can be fragile. > > > May be it has sense to check the app arguments and java options only if LIBC is defined and it equals to musl. > > One more interesting question is if the test passes on AIX because AIX also requires the modified LD_LIBRARY_PATH and the test should fail for the same reason. > > > [1] https://hg.openjdk.java.net/portola/portola/file/7ff60204a181/src/java.base… > > [2] https://hg.openjdk.java.net/portola/portola/file/7ff60204a181/src/java.base… > > Thanks, > > Alexander. >

1 0

RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF)
by Langer, Christoph 20 Feb '20

20 Feb '20

Hi, please help reviewing the contribution of the support for the AIX Input Method Editor (IME) in AWT's Input Method Framework. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 I took Ichiroh's initial proposal [1] and tried to integrate it better with existing code. I have split src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into a) a base class containing the common code: src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java b) a specific class for the common Linux/Unixes: src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and c) a specific class for AIX: src/java.desktop/aix/classes/sun/awt/X11InputMethod.java The AIX specific additions to the native code of src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so much that I decided to add a specific implementation file for AIX: src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The changes to the former file are some cleanups. I'm still in the process of testing the changes - but maybe you can run further tests, especially on non-AIX unixes to make sure we didn't break something. Thanks & Best regards Christoph [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013869.html

5 10

Optimization to improve biased locking in Hadoop Map tasks for ppc64le on jdk8u
by Ting YY Wang 13 Jan '20

13 Jan '20

This is not a RFR, but I want to share my prototype implementation for optimizations in the biased locking. I provide code for ppc64le due to my limited resource availability, though it should be general purpose for all the platforms in nature. Background: I found two interesting situations. (1) At the beginning of deoptimization process, all biased locks are revoked, so that later they can be inflated and then moved from compiled frame to interpreter frame. (2) Periodic lock contention occurs from background thread (e.g. TaskReporter in Hadoop). Lock bias will be revoked due to the contention, and there is less chance that lock can maintain bias. Proposal: (1) Enhance deoptimization to keep locks biased. Once vframeArray is created by create_vframeArray, it is guaranteed there will be no safepoint until fields are rematerialized. So this is a equal guarantee that lock biased state will be preserved during this period, and it is possible to simply move lock from compiled frame to interpreter frame without inflate (Thanks to the comments in BasicLock::move_to()). (2) Eagerly manipulate to biased state for target lock states if possible. To determine the target locks, my approach uses profiling to identify locks that are hot and accessed by a single thread. Prototype implementation: http://cr.openjdk.java.net/~mhorie/bl/webrev/ Let me know if this hack can benefit your workload, and any comments are welcomed. Thanks! Best Regards, Felix Wang (王挺, Ting Wang) ----------------------------- OpenPOWER PoC/Performance IBM GCG Systems & Technology Lab Tel: (86-21) 6092-2393 Mobile: (86) 135-8554-9659 E-Mail: wtingsh(a)cn.ibm.com

2 3

Re: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes
by Nick Gasson 17 Dec '19

17 Dec '19

On 12/12/2019 04:16, Andrew Haley wrote: > On 12/11/19 7:08 AM, Nick Gasson wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 >> Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ > > Thanks. A few nits: Please see the updated webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.02/ > > This recalculates klass_decode_mode() a thousand times on only a small > program. Be aware that C2 creates a new Assembler instance for most patterns. > > _klass_decode_mode could be calculated only once. Make it static and it > will be. Yes. Also added an assert that Metaspace::initialized() in case we call it too early. > > This inverted logic: > > #if !(defined(AARCH64) || defined(AIX)) > return ReservedSpace(size, alignment, large_pages, requested_addr); > #else // AARCH64 || AIX > > looks a bit cumbersome. It might be nice to do it the other way up, so > that reserve_preferred_space is called from a static generic allocate > method. > > Rather than explicitly defined(AARCH64) || defined(AIX) you might like to > consider a named macro > > #if OS_CPU_USES_PREFERRED_SPACE > return reserve_preferred_space( ... > endif > OK. Metaspace::reserve_preferred_space() is now only defined if PREFERRED_METASPACE_ALIGNMENT is set. The generic method is Metaspace::reserve_space(). MetaspaceShared::reserve_shared_space() is now just a trivial wrapper for this so maybe it can be removed. I put the definition in the CPU's globalDefinitions.hpp because we don't have one for os_cpu, and we need it for every AArch64 system anyway. Also fixed the break/return inconsistency suggested by Jiangli. Thanks, Nick

2 2

Re: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah?
by Liu Xin 12 Dec '19

12 Dec '19

hi, Martin and Andrew, Thank you to point out that JBS issue. I can backport and validate that. Yes, if powerpc doesn't have C1 in jdk8u, than it's safe. it's only about aarch64. thanks, --lx On Thu, Dec 12, 2019 at 2:18 AM Andrew Haley <aph(a)redhat.com> wrote: > On 12/12/19 9:36 AM, Doerr, Martin wrote: > > seems like the following issue should get backported: > > https://bugs.openjdk.java.net/browse/JDK-8135018 > > > > Btw. I believe PPC is fine because C1 is not supported in 8u (at least > not in the official repo). > > Oh yes, that's one of mine. We should backport it. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > >

1 0

does C1+CMS miss a storestore membar in jdk8u-shenandoah?
by Liu Xin 12 Dec '19

12 Dec '19

Hi, Aarch64 & PowerPC community, I think this is only for arm and ppc because only they are use relaxed memory ordering. x86 and sparc use TSO so storestore membar doesn't matter for them. please correct me if I am wrong. I feel that C1's LIRGenerator::CardTableModRef_post_barrier(c1_LIRGenerator.cpp) misses a storestore membar for CMS on jdk8u. Could you review my observation? If I am right, I'd like to file a bug and fix it. One reference is oop.inline.hpp. CMS uses the following function: template <class T> inline void oop_store(volatile T* p, oop v) It will emit a write_mem_barrier before cardTable updates. Another reference is C2 code. GraphKit::write_barrier_post generates storeCM for CMS. // Smash zero into card if( !UseConcMarkSweepGC ) { __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release); } else { // Specialized path for CM store barrier __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, adr_type); } Actually, it's not only C1 has this bug. Template interpreter has this problem too. It only happens for aarch64. do_oop_store in templateTable_aarch64.cpp doesn't have any membar for CMS. By contrast, ppc64 does have a membar(StoreStore). (macroAssembly_ppc.cpp) // Write the card table byte. void MacroAssembler::card_table_write(jbyte* byte_map_base, Register Rtmp, Register Robj) { assert_different_registers(Robj, Rtmp, R0); load_const_optimized(Rtmp, (address)byte_map_base, R0); srdi(Robj, Robj, CardTableModRefBS::card_shift); li(R0, 0); // dirty if (UseConcMarkSweepGC) membar(Assembler::StoreStore); stbx(R0, Rtmp, Robj); } I also check the jdk11 and jdk14, c1 and template interpreter both consider concurrent_scanning case. please check out the following functions. so only jdk8u is at risk. CardTableBarrierSetC1::post_barrier CardTableBarrierSetAssembler::store_check thanks, --lx

2 1

RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes
by Nick Gasson 11 Dec '19

11 Dec '19

Hi, Please help to review this patch to fix some issues uncovered by CDS archive relocation. Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ As a bit of background, on AArch64 there are a few different ways we can decode/encode compressed klass pointers, depending on the base address alignment and shift. (1) If the base is NULL then it's a no-op or shift. (2) If we can encode the the base as a logical immediate, use an EOR instruction to encode/decode. (3) If the base is 4G aligned and the shift is zero, use a MOVK instruction to combine the base and offset. (4) Otherwise emit an inefficient sequence using rheapbase as a temporary, and then restore the heap base (poorly tested). On AArch64 and AIX we have a loop in Metaspace::allocate_metaspace_compressed_klass_ptrs that searches for a 4G aligned location to map the compressed class space and enable optimisations (2) and (3) above. It's possible to fail and fall through to (4) after mmap-ing at an arbitrary address, but I think in practice this never happens. MetaspaceShared allocates the compressed class space in a different way, but the default base address is 0x80000000 which allows method (2) above. After the changes in 8231610 the CDS archive can be relocated to an arbitrary location decided by mmap, which makes case (4) much more likely. The test case in the title passes -XX:HeapBaseMinAddress=33g which triggers the CDS relocation. The combination of (4) and the extra shift/add from the non-NULL narrow OOP base overflows the itable stub code buffer. I want to fix this by ensuring that the compressed klass space is always at least 4G aligned on AArch64 so we can get rid of (4). This will reduce the variability in code size from memory layout, reduce the number of configurations we need to test, and makes repurposing rheapbase easier (see the review thread for 8233743). This patch moves the AArch64/AIX address space search loop into a new function Metaspace::reserve_preferred_space. MetaspaceShared::reserve_shared_space now calls this rather than directly constructing the ReservedSpace. If use_requested_addr is false it will search for a suitably aligned location (replacement for ReservedSpace() with requested_addr=NULL), otherwise it checks the fixed address meets the alignment requirements. Should be no functional change on platforms other than AArch64 and AIX. Additionally, to support method (3) when the compressed klass shift is non-zero (which it always is when CDS is on), the compressed klass base will be aligned to a (4 << LogKlassAlignmentInBytes)*G boundary when the base is above 32GB (limit for zero-based address). This allows us to shift the base address right LogKlassAlignmentInBytes bits and use MOVK to add it to the offset (discarding the lower 32 bits). I added an extra case to SharedBaseAddress.java to cover this during jtreg testing. Finally there's a small bug in the existing code to determine if we can use the EOR optimisation (2). use_XOR_for_compressed_class_base = operand_valid_for_logical_immediate (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) && ((uint64_t)CompressedKlassPointers::base() > (1UL << log2_intptr(CompressedKlassPointers::range()))); This doesn't work if e.g. the base is 0x180000000 and the rounded-up range is 0x100000000 because the high significant bits of the compressed pointer overlap with the low significant bits of the base, even though the base is strictly greater than the range. So the following will SEGV with the current VM: java -Xmx128m -XX:SharedBaseAddress=6g -Xshare:dump Fixed this and moved all the logic for deciding which scheme to use into MacroAssembler::klass_decode_mode. Tested jtreg hotspot_all_no_apps, jdk_core on AArch64 and x86. Also did some manual testing with -XX:SharedBaseAddress and -XX:ArchiveRelocationMode=1 (thanks Ioi). I'm not able to test on AIX which shares the same metaspace code (CC'd ppc-aix-port-dev). Thanks, Nick

3 2