From rwestrel at redhat.com Mon Oct 1 10:09:24 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 01 Oct 2018 12:09:24 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value Message-ID: http://cr.openjdk.java.net/~roland/8211320/webrev.00/ Intrinsics for unsafe.compareAndSetByte() and unsafe.compareAndSetShort() don't properly deal with sign extension: load exclusive doesn't sign extend loaded value but comparison is done with sign extended value. Roland. From aph at redhat.com Mon Oct 1 10:13:59 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 11:13:59 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> <68b52c1a-63c0-9966-2627-db4de08e7c46@samersoff.net> Message-ID: <0161d6e0-809b-c729-0bcb-b76890f63d6e@redhat.com> On 09/29/2018 11:01 AM, Pengfei Li (Arm Technology China) wrote: > Anyone can help push Andrew Haley's fix ASAP since current master cannot build? > http://cr.openjdk.java.net/~aph/8211207/ It's in. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Oct 1 10:43:29 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 1 Oct 2018 11:43:29 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: Message-ID: <2369f83b-6edf-ef36-2a4a-0a81667e7251@redhat.com> On 01/10/18 11:09, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8211320/webrev.00/ > > Intrinsics for unsafe.compareAndSetByte() and > unsafe.compareAndSetShort() don't properly deal with sign extension: > load exclusive doesn't sign extend loaded value but comparison is done > with sign extended value. Looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Mon Oct 1 10:43:51 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 11:43:51 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: Message-ID: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> On 10/01/2018 11:09 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8211320/webrev.00/ > > Intrinsics for unsafe.compareAndSetByte() and > unsafe.compareAndSetShort() don't properly deal with sign extension: > load exclusive doesn't sign extend loaded value but comparison is done > with sign extended value. Ooh, that's tricky. I wonder if we should do this inside cmpxchg(). Mind you, that would cause cmpxchg() to have a side effect on an input operand. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Oct 1 10:50:08 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 1 Oct 2018 11:50:08 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> Message-ID: <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> On 01/10/18 11:43, Andrew Haley wrote: > On 10/01/2018 11:09 AM, Roland Westrelin wrote: >> >> http://cr.openjdk.java.net/~roland/8211320/webrev.00/ >> >> Intrinsics for unsafe.compareAndSetByte() and >> unsafe.compareAndSetShort() don't properly deal with sign extension: >> load exclusive doesn't sign extend loaded value but comparison is done >> with sign extended value. > > Ooh, that's tricky. I wonder if we should do this inside cmpxchg(). > Mind you, that would cause cmpxchg() to have a side effect on an input > operand. You seem to have answered that question (correctly?) in the negative :-) If you moved the sign extend into the cmpxchg method the C2 code would still have to copy the input to a temporary register and pass the temp into cmpxchg. Since this is the only place where a cmpxchgb actually occurs that doesn't seem like a better solution. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Mon Oct 1 11:03:20 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 12:03:20 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> Message-ID: <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> On 10/01/2018 11:50 AM, Andrew Dinn wrote: > On 01/10/18 11:43, Andrew Haley wrote: >> On 10/01/2018 11:09 AM, Roland Westrelin wrote: >>> >>> http://cr.openjdk.java.net/~roland/8211320/webrev.00/ >>> >>> Intrinsics for unsafe.compareAndSetByte() and >>> unsafe.compareAndSetShort() don't properly deal with sign extension: >>> load exclusive doesn't sign extend loaded value but comparison is done >>> with sign extended value. >> >> Ooh, that's tricky. I wonder if we should do this inside cmpxchg(). >> Mind you, that would cause cmpxchg() to have a side effect on an input >> operand. > You seem to have answered that question (correctly?) in the negative :-) IMO it's more complicated than that. > If you moved the sign extend into the cmpxchg method the C2 code would > still have to copy the input to a temporary register and pass the temp > into cmpxchg. Since this is the only place where a cmpxchgb actually > occurs that doesn't seem like a better solution. The problem is that cmpxchg() is a trap for the unwary. The alternative would be to have cmpxchg itself do the sign extension on the output. I guess it all depends on what the LSE instructions do, given that we don't want to have different results on a machine that supports LSE. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 1 13:18:37 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 14:18:37 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> Message-ID: On 10/01/2018 12:03 PM, Andrew Haley wrote: > The alternative would be to have cmpxchg itself do the sign extension > on the output. I guess it all depends on what the LSE instructions do, > given that we don't want to have different results on a machine that > supports LSE. I'm looking at the LSE spec, and it compares the memory with the sub- word (of whatever size) in the passed register. The equivalent for us would be bind(retry_load); load_exclusive(result, addr, size, acquire); if (size == xword) { cmp(result, expected); } else if (size == word) { cmpw(result, expected); } else if (size == hword) { andr(rscratch1, expected, 0xffff); cmpw(result, rscratch1); } else if (size == byte) { andr(rscratch1, expected, 0xff); cmpw(result, rscratch1); } else { ShouldNotReachHere(); } br(Assembler::NE, done); It'd be better with a switch, but you get the idea. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Oct 1 13:19:21 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 1 Oct 2018 14:19:21 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> Message-ID: On 01/10/18 12:03, Andrew Haley wrote: > On 10/01/2018 11:50 AM, Andrew Dinn wrote: >> On 01/10/18 11:43, Andrew Haley wrote: >> You seem to have answered that question (correctly?) in the negative :-) > > IMO it's more complicated than that. > >> If you moved the sign extend into the cmpxchg method the C2 code would >> still have to copy the input to a temporary register and pass the temp >> into cmpxchg. Since this is the only place where a cmpxchgb actually >> occurs that doesn't seem like a better solution. > > The problem is that cmpxchg() is a trap for the unwary. > > The alternative would be to have cmpxchg itself do the sign extension > on the output. I guess it all depends on what the LSE instructions do, > given that we don't want to have different results on a machine that > supports LSE. Just to be precise here I should, of course, have said 'if you moved the /unsigned/ extend into the cmpxchg method ...' I take your point that this is a trap because as currently coded cmpxchg will load an unsigned byte or half-word and perform a 32-bit compare against the value held in register oldval. Now, that's only a trap because byte and half-word values are conventionally passed around internally in registers as /signed/ 32-bit values. Normally, loads and stores enforce the necessary unsigned to signed conversion. So, in this one case, where the load does not (cannot) do sign extension, in order to get the correct comparison the caller or callee must massage the register value with an unsigned extend before calling cmpxchg. So, what I had assumed you were suggesting was that the callee, cmpxchg, should perform the unsigned extension on the input value. However, it appears that unsigned extension, whether by caller or callee, is not the right fix because it does not deal with a related problem. In the current usage result is passed as noreg. However, if result were supplied as a writeable register, to be assigned the loaded byte or short value, then that value would be handed out /unsigned/, breaking the convention that loaded byte or short values are installed into a register sign-extended. So, the correct fix is to sign-extend result after the load if needed i.e. . . . bind(retry_load); load_exclusive(result, addr, size, acquire); if (size == byte) { sxtbw(result, result); } else if (size == byte) { sxthw(result, result); } if (size == xword) cmp(result, expected); else { cmpw(result, expected); br(Assembler::NE, done); . . . regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Mon Oct 1 13:28:57 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 14:28:57 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> Message-ID: <738ba341-acb6-71f4-56c3-bea0be009438@redhat.com> On 10/01/2018 02:18 PM, Andrew Haley wrote: > It'd be better with a switch, but you get the idea. Ahh, not quite, because rscratch1 might be result. So we'd have to handle the result == noreg case separately. But we could still do it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 1 13:30:18 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 14:30:18 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> Message-ID: <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> On 10/01/2018 02:19 PM, Andrew Dinn wrote: > So, in this > one case, where the load does not (cannot) do sign extension, in order > to get the correct comparison the caller or callee must massage the > register value with an unsigned extend before calling cmpxchg. So, what > I had assumed you were suggesting was that the callee, cmpxchg, should > perform the unsigned extension on the input value. Yes, I am, but in a way that does not alter the input operand. Whatever it does must not have any side effects beyond clobbering rscratch1. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 1 13:35:52 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 14:35:52 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> Message-ID: Like this: bind(retry_load); load_exclusive(result, addr, size, acquire); if (size == xword) { cmp(result, expected); } else if (size == word) { cmpw(result, expected); } else if (size == hword) { eorw(rscratch1, result, expected); ands(zr, rscratch1, 0xffff); } else if (size == byte) { eorw(rscratch1, result, expected); ands(zr, rscratch1, 0xff); } else { ShouldNotReachHere(); } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 1 17:13:38 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 18:13:38 +0100 Subject: [aarch64-port-dev ] 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls Message-ID: The jdk8u patch for 8211064 includes a new test case. It is, like all such cases, shared code. Do we need to ask for a review of this test case upstream? Or maybe we can just push the fix into our aarch64 jdk8u repo, not the testcase? Not sure how to handle this. It's pretty trivial, I'm tempted just to push the fix to aarch64/jdk8u and forget about the new testcase. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 1 17:24:36 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 18:24:36 +0100 Subject: [aarch64-port-dev ] 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls In-Reply-To: References: Message-ID: On 10/01/2018 06:13 PM, Andrew Haley wrote: > The jdk8u patch for 8211064 includes a new test case. It is, like all such > cases, shared code. Never mind, I've figured out what to do. http://cr.openjdk.java.net/~aph/8211064-2/ OK? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Oct 1 17:27:39 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Oct 2018 19:27:39 +0200 Subject: [aarch64-port-dev ] 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls In-Reply-To: References: Message-ID: On 10/01/2018 07:24 PM, Andrew Haley wrote: > On 10/01/2018 06:13 PM, Andrew Haley wrote: >> The jdk8u patch for 8211064 includes a new test case. It is, like all such >> cases, shared code. > > Never mind, I've figured out what to do. > > http://cr.openjdk.java.net/~aph/8211064-2/ Wait a minute, why T_CHAR here? templateInterpreter_aarch64.cpp: 288 case T_BOOLEAN: __ uxtb(r0, r0); break; 289 case T_CHAR : __ c2bool(r0); break; Otherwise seems fine. -Aleksey From aph at redhat.com Tue Oct 2 13:01:02 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Oct 2018 14:01:02 +0100 Subject: [aarch64-port-dev ] 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls In-Reply-To: References: Message-ID: On 10/01/2018 06:27 PM, Aleksey Shipilev wrote: > On 10/01/2018 07:24 PM, Andrew Haley wrote: >> On 10/01/2018 06:13 PM, Andrew Haley wrote: >>> The jdk8u patch for 8211064 includes a new test case. It is, like all such >>> cases, shared code. >> >> Never mind, I've figured out what to do. >> >> http://cr.openjdk.java.net/~aph/8211064-2/ > > Wait a minute, why T_CHAR here? > > templateInterpreter_aarch64.cpp: > > 288 case T_BOOLEAN: __ uxtb(r0, r0); break; > 289 case T_CHAR : __ c2bool(r0); break; Great catch, thanks. I misapplied the patch. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Oct 2 13:37:10 2018 From: aph at redhat.com (aph at redhat.com) Date: Tue, 02 Oct 2018 13:37:10 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls Message-ID: <201810021337.w92DbARA015070@aojmv0008.oracle.com> Changeset: 366850267073 Author: aph Date: 2018-10-02 09:16 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/366850267073 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls Contributed-by: apetushkov Reviewed-by: aph ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp From aph at redhat.com Tue Oct 2 14:57:09 2018 From: aph at redhat.com (aph at redhat.com) Date: Tue, 02 Oct 2018 14:57:09 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 2 new changesets Message-ID: <201810021457.w92Ev9iK029561@aojmv0008.oracle.com> Changeset: 96d806855d19 Author: aph Date: 2018-10-02 09:16 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/96d806855d19 8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls Contributed-by: apetushkov Reviewed-by: aph ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Changeset: c763810a9bf5 Author: fyang Date: 2018-09-28 08:48 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c763810a9bf5 8207838: AArch64: Float registers incorrectly restored in JNI call Summary: fix the order in which float registers are restored in restore_args for aarch64 Reviewed-by: aph Contributed-by: guoge1 at huawei.com ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp + test/compiler/floatingpoint/8165673/TestFloatJNIArgs.java + test/compiler/floatingpoint/8165673/TestFloatJNIArgs.sh + test/compiler/floatingpoint/8165673/libTestFloatJNIArgs.c + test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.java + test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.sh + test/compiler/floatingpoint/8207838/libTestFloatSyncJNIArgs.c - test/compiler/floatingpoint/TestFloatJNIArgs.java - test/compiler/floatingpoint/TestFloatJNIArgs.sh - test/compiler/floatingpoint/libTestFloatJNIArgs.c From stuart.monteith at linaro.org Tue Oct 2 21:54:42 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 2 Oct 2018 22:54:42 +0100 Subject: [aarch64-port-dev ] RFC: 64 bit literal oops Message-ID: Hello, I've been testing my patch to make literal oops 64-bit rather than 48-bit. This is a necessary prerequisite for ZGC to operate on aarch64 using tagged pointers. I'm not submitting this in it's final form, but just for a view on whether this is the proper way to do this. The patch is here: http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ I've tested it against jtreg and G1GC, and get clean results as compared to without the patch. No issues are apparent running SPECjbb-2015. There are essentially 7 changes: 1. There is a new options: -XX:+Use64BitLiteralOops 2. MacroAssembler::patch_oop(address,address) patches 64-bit addresses if the flag is enabled. 3. MacroAssembler::target_addr_for_insn(address, unsigned) is modified to pull out a 64-bit target address, if there is an extra movk, and then calls ShouldNotReachHere(). 4. MacroAssembler::mov(Register, Address) has been changed to call movptr with a flag set if the address is an Oop. 5. MacroAssembler::movptr(Register, uintptr_t) has been modified to take a flag indicating if it is an oop that is being emitted. If Use64BitLiteralOops has been set, then an additional movk is emitted to make up the 64 bit literal. 6. NativeInstruction::is_oop_at(int) was added, to detect if an oop exists at the address. 7. NativeMovConstReg::next_instruction_address() has been changed to handle get the address after "movz, movk, movk" and with 64 bit oops "movz, movk, movk, movk." (6) has never been observed,, so I don't consider it tested - there aren't circumstances where it returns true, so arguably it it should be replaced by an appropriate assert. Likewise, (3) is also an unnecessary change - the ShouldNotReachHere() never traps during testing - it was left in for review purposes. It has been mentioned to me that we could just use 64-bit literals, as that would make things simpler - I look forward to people's opinions. It was also mentioned ages ago that in future the coloured bits could be made irrelevant for ZGC. There is the up and coming 52-bit VA scheme for Arm v8. If we are to use >48 bits of address space we will have to ask for it explicitly, in which case we'd need to use 64 bit oops. The class metadata could remain 48-bit in that case. There is an interesting presentation on 52-bit VA here: https://connect.linaro.org/resources/yvr18/yvr18-119/ BR, Stuart From rwestrel at redhat.com Thu Oct 4 07:19:34 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 04 Oct 2018 09:19:34 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> Message-ID: Ok. Here is a new webrev: http://cr.openjdk.java.net/~roland/8211320/webrev.01/ Roland. From aph at redhat.com Thu Oct 4 08:26:06 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Oct 2018 09:26:06 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> Message-ID: <7e5f4ce4-0169-7eed-d6c6-c62fd3f85e10@redhat.com> On 10/04/2018 08:19 AM, Roland Westrelin wrote: > Ok. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8211320/webrev.01/ Yes, that looks like a safer solution. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Fri Oct 5 07:42:55 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 05 Oct 2018 09:42:55 +0200 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations Message-ID: http://cr.openjdk.java.net/~roland/8209835/webrev.00/ This adds barrier elision support for all volatile operations that were not supported so far and extends the tests to cover all of them. I ran full jcstress successfully with this. Roland. From adinn at redhat.com Fri Oct 5 09:04:11 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 5 Oct 2018 10:04:11 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: Message-ID: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> On 05/10/18 08:42, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8209835/webrev.00/ > > This adds barrier elision support for all volatile operations that were > not supported so far and extends the tests to cover all of them. I ran > full jcstress successfully with this. Yes, that looks good. Did you also eyeball the generated code? I know jcstress ought to find any bugs but it would be good to be doubly sure :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From rwestrel at redhat.com Fri Oct 5 09:10:52 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 05 Oct 2018 11:10:52 +0200 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> Message-ID: >> http://cr.openjdk.java.net/~roland/8209835/webrev.00/ >> >> This adds barrier elision support for all volatile operations that were >> not supported so far and extends the tests to cover all of them. I ran >> full jcstress successfully with this. > Yes, that looks good. Thanks for the review. > Did you also eyeball the generated code? I know jcstress ought to find > any bugs but it would be good to be doubly sure :-) I didn't eyeball the code (there's a lot to check!). I extended tests to cover all combination of atomic operations/argument types. So at least, tests should guarantee that the right variant in the ad file is picked. Then, of course, all variants must be correctly implemented. For that, I checked a couple times that the right boolean flag was passed. Roland. From adinn at redhat.com Fri Oct 5 10:30:35 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 5 Oct 2018 11:30:35 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> Message-ID: <34901832-0f15-a984-3dc1-184d90780f5a@redhat.com> On 05/10/18 10:10, Roland Westrelin wrote: > >>> http://cr.openjdk.java.net/~roland/8209835/webrev.00/ >>> >>> This adds barrier elision support for all volatile operations that were >>> not supported so far and extends the tests to cover all of them. I ran >>> full jcstress successfully with this. >> Yes, that looks good. > > Thanks for the review. > >> Did you also eyeball the generated code? I know jcstress ought to find >> any bugs but it would be good to be doubly sure :-) > > I didn't eyeball the code (there's a lot to check!). I extended tests to > cover all combination of atomic operations/argument types. So at least, > tests should guarantee that the right variant in the ad file is > picked. Then, of course, all variants must be correctly implemented. For > that, I checked a couple times that the right boolean flag was passed. Yes, I noted the updates to the test code and they should ensure that the generated code has the right instruction sequence. That's an ok from me then. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Tue Oct 9 16:32:16 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 9 Oct 2018 17:32:16 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> Message-ID: <01019d3e-974b-c472-5ca3-aac1d1329af1@redhat.com> On 10/04/2018 08:19 AM, Roland Westrelin wrote: > Ok. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8211320/webrev.01/ I'm getting many test failures in my debug build because of nag messages for things like CMS deprecation and TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: stderr was not empty There must be some way to make jtreg ignore the noise, surely. I don't know how you managed to run the tests. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Thu Oct 11 08:05:28 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 11 Oct 2018 10:05:28 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <01019d3e-974b-c472-5ca3-aac1d1329af1@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> <01019d3e-974b-c472-5ca3-aac1d1329af1@redhat.com> Message-ID: > I'm getting many test failures in my debug build because of nag messages > for things like CMS deprecation and > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: stderr was not empty > > There must be some way to make jtreg ignore the noise, surely. I don't know > how you managed to run the tests. Are you trying to run this bug's test (which has nothing to do with CMS)? Or are you talking about 8209835 "Aarch64: elide barriers on all volatile operations" (which runs some subtest with CMS)? Anyway, I updated to current jdk/jdk, rebased, rebuilt and I can run the tests of both bugs fine with: jtreg -ignore:quiet -conc:8 -dir:/test/hotspot/jtreg -compilejdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -testjdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -va -javaoptions:'-server' compiler/c2/aarch64/ and jtreg -ignore:quiet -conc:8 -dir:/test/hotspot/jtreg -compilejdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -testjdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -va -javaoptions:'-server' compiler/unsafe/CASandCAEwithNegExpected.java Roland. From aph at redhat.com Thu Oct 11 10:37:19 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Oct 2018 11:37:19 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> <01019d3e-974b-c472-5ca3-aac1d1329af1@redhat.com> Message-ID: <7d2ea055-de13-0a1c-64e6-4c9067a04cd6@redhat.com> On 10/11/2018 09:05 AM, Roland Westrelin wrote: > >> I'm getting many test failures in my debug build because of nag messages >> for things like CMS deprecation and >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: stderr was not empty >> >> There must be some way to make jtreg ignore the noise, surely. I don't know >> how you managed to run the tests. > > Are you trying to run this bug's test (which has nothing to do with > CMS)? Or are you talking about 8209835 "Aarch64: elide barriers on all > volatile operations" (which runs some subtest with CMS)? > > Anyway, I updated to current jdk/jdk, rebased, rebuilt and I can run the > tests of both bugs fine with: > > jtreg -ignore:quiet -conc:8 -dir:/test/hotspot/jtreg -compilejdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -testjdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -va -javaoptions:'-server' compiler/c2/aarch64/ > > and > > jtreg -ignore:quiet -conc:8 -dir:/test/hotspot/jtreg -compilejdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -testjdk:/build/linux-aarch64-normal-server-fastdebug/images/jdk -va -javaoptions:'-server' compiler/unsafe/CASandCAEwithNegExpected.java Exactly the same: $ jtreg -ignore:quiet -conc:8 -dir:$JDK/test/hotspot/jtreg \ -compilejdk:$JDK/build/linux-aarch64-server-fastdebug/images/jdk \ -testjdk:$JDK/build/linux-aarch64-server-fastdebug/images/jdk -va \ -javaoptions:'-server' compiler/c2/aarch64/ ... --add-modules java.base \ --add-exports java.base/jdk.internal.misc=ALL-UNNAMED \ -server \ com.sun.javatest.regtest.agent.MainWrapper /local/x/JTwork/compiler/c2/aarch64/TestVolatilesG1.d/driver.6.jta TestUnsafeVolatileCAS G1 TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: stderr was not empty I don't understand what is going on. Can you try with jtreg-4.2-b13.tar.gz from https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Oct 12 17:58:33 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Oct 2018 18:58:33 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> <01019d3e-974b-c472-5ca3-aac1d1329af1@redhat.com> Message-ID: <1c26fa37-5c78-c3f6-48cf-f3c9870c0980@redhat.com> On 10/11/2018 09:05 AM, Roland Westrelin wrote: > Are you trying to run this bug's test (which has nothing to do with > CMS)? Or are you talking about 8209835 "Aarch64: elide barriers on all > volatile operations" (which runs some subtest with CMS)? Yeah, I get it now, sorry. You're quite right: the tests for this patch and 8209835 are together in the same dir and we need both patches for everything to succeed. The patch is good, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Oct 12 18:41:00 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Oct 2018 19:41:00 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> Message-ID: <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> On 10/05/2018 10:10 AM, Roland Westrelin wrote: > >>> http://cr.openjdk.java.net/~roland/8209835/webrev.00/ >>> >>> This adds barrier elision support for all volatile operations that were >>> not supported so far and extends the tests to cover all of them. I ran >>> full jcstress successfully with this. >> Yes, that looks good. > > Thanks for the review. > >> Did you also eyeball the generated code? I know jcstress ought to find >> any bugs but it would be good to be doubly sure :-) > > I didn't eyeball the code (there's a lot to check!). I extended tests to > cover all combination of atomic operations/argument types. So at least, > tests should guarantee that the right variant in the ad file is > picked. Then, of course, all variants must be correctly implemented. For > that, I checked a couple times that the right boolean flag was passed. I want to eyeball the code, but I just spent the last hour and a half trying to figure out how to get real assembly code (not OptoAssembly) out of jtreg. It seems incredibly difficult: everything is conspiring to stop it from happening. If I edit the tests so that PrintAssembly is passed, the tests fail. In desperation I am about to edit HotSpot so that the assembly output goes to a named pipe, but i can't help feeling that it really should be easier than this. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Mon Oct 15 11:01:40 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 15 Oct 2018 12:01:40 +0100 Subject: [aarch64-port-dev ] jdk/jdk ci builds Message-ID: Hello, I've added a new build that is triggered once an hour if there has been a change to the jdk/jdk repository. It does nothing more than build a fast debug build, so it exists just to catch code that introduces build failures. Emails will be sent on the first failure, and once the build has been fixed. All of the builds, successful or otherwise, can be seen here: https://ci.linaro.org/job/jdkX-ci-build/ This is on the original build machine which got overloaded and eventually broke. There should be proper daily builds coming from it's replacement soon. BR, Stuart From stuart.monteith at linaro.org Mon Oct 15 12:47:26 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 15 Oct 2018 13:47:26 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> Message-ID: Hi, I'd like to do the same. I've came up with this: java -XX:+PrintAssembly -XX:+LogVMOutput -XX:LogFile="test-%p.log" -XX:+DebugNonSafepoints -XX:-DisplayVMOutput -version Of course, if the test relies on the logging being set certain different way, there'll be more problems. BR, Stuart On Fri, 12 Oct 2018 at 19:41, Andrew Haley wrote: > > On 10/05/2018 10:10 AM, Roland Westrelin wrote: > > > >>> http://cr.openjdk.java.net/~roland/8209835/webrev.00/ > >>> > >>> This adds barrier elision support for all volatile operations that were > >>> not supported so far and extends the tests to cover all of them. I ran > >>> full jcstress successfully with this. > >> Yes, that looks good. > > > > Thanks for the review. > > > >> Did you also eyeball the generated code? I know jcstress ought to find > >> any bugs but it would be good to be doubly sure :-) > > > > I didn't eyeball the code (there's a lot to check!). I extended tests to > > cover all combination of atomic operations/argument types. So at least, > > tests should guarantee that the right variant in the ad file is > > picked. Then, of course, all variants must be correctly implemented. For > > that, I checked a couple times that the right boolean flag was passed. > > I want to eyeball the code, but I just spent the last hour and a half > trying to figure out how to get real assembly code (not OptoAssembly) > out of jtreg. It seems incredibly difficult: everything is conspiring > to stop it from happening. If I edit the tests so that PrintAssembly > is passed, the tests fail. > > In desperation I am about to edit HotSpot so that the assembly output > goes to a named pipe, but i can't help feeling that it really should > be easier than this. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 15 13:42:09 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Oct 2018 14:42:09 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> Message-ID: On 10/15/2018 01:47 PM, Stuart Monteith wrote: > I'd like to do the same. I've came up with this: > > java -XX:+PrintAssembly -XX:+LogVMOutput > -XX:LogFile="test-%p.log" -XX:+DebugNonSafepoints -XX:-DisplayVMOutput > -version > > Of course, if the test relies on the logging being set certain > different way, there'll be more problems. Yea, thanks. I've had to do it slightly differently, but I'm going now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Oct 15 15:57:37 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Oct 2018 16:57:37 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> Message-ID: Andrew Dinn wrote: > I didn't eyeball the code (there's a lot to check!). I extended tests to > cover all combination of atomic operations/argument types. So at least, > tests should guarantee that the right variant in the ad file is > picked. Then, of course, all variants must be correctly implemented. For > that, I checked a couple times that the right boolean flag was passed. I have been eyeballing the code, and I see one problem: public void testInt(int x, int i) { unsafe.compareAndExchangeInt(this, f_int_off, x, i); } These methods don't test the return value at all. We really need to check the return value is correctly sign- or zero-extended and compressed Oops are correctly decoded. The generated code itself looks fine. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Oct 16 08:27:46 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Oct 2018 09:27:46 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> Message-ID: <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> On 10/15/2018 04:57 PM, Andrew Haley wrote: > Andrew Dinn wrote: > >> I didn't eyeball the code (there's a lot to check!). I extended tests to >> cover all combination of atomic operations/argument types. So at least, >> tests should guarantee that the right variant in the ad file is >> picked. Then, of course, all variants must be correctly implemented. For >> that, I checked a couple times that the right boolean flag was passed. I tested on a ThunderX2 machine with the LSE instruction set, and the jtreg tests all pass. I'll do a jcstress test on that box too, just to be sure. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Oct 16 09:04:35 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Oct 2018 10:04:35 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> Message-ID: <151af3d7-e13b-03c9-65d9-2b69c458085e@redhat.com> On 10/16/2018 09:27 AM, Andrew Haley wrote: > I tested on a ThunderX2 machine with the LSE instruction set, and the > jtreg tests all pass. I'll do a jcstress test on that box too, just to > be sure. I see failures here: [FAILED] o.o.j.t.atomicity.varHandles.fields.GetAndSetTest.GetAndSetByte (fork: #1, iteration #0, JVM args: [-XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]) Observed state Occurrences Expectation Interpretation 0, -1, 2 5,588 ACCEPTABLE actor1 execute before actor2 0, 0, -1 0 FORBIDDEN This won't happen because getAndSet is atomic 0, 0, 2 0 FORBIDDEN This won't happen because getAndSet is atomic 0, 2, 2 322,083 FORBIDDEN No default case provided, assume FORBIDDEN 2, 0, -1 0 ACCEPTABLE actor1 execute after actor2 Once the entire jcstress run is complete I'll have a look to see what is wrong. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Tue Oct 16 14:58:55 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 16 Oct 2018 16:58:55 +0200 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> Message-ID: > I have been eyeballing the code, and I see one problem: > > public void testInt(int x, int i) > { > unsafe.compareAndExchangeInt(this, f_int_off, x, i); > } > > These methods don't test the return value at all. We really need > to check the return value is correctly sign- or zero-extended and > compressed Oops are correctly decoded. Here is an updated webrev with your suggested test change: http://cr.openjdk.java.net/~roland/8209835/webrev.01/ And the incremental webrev: http://cr.openjdk.java.net/~roland/8209835/webrev.00-01/ The card marking store is not always before on after the cmpxchg itself so I had to tweak the harness itself. Roland. From aph at redhat.com Tue Oct 16 16:47:57 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Oct 2018 17:47:57 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <151af3d7-e13b-03c9-65d9-2b69c458085e@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> <151af3d7-e13b-03c9-65d9-2b69c458085e@redhat.com> Message-ID: <956eb418-6926-3f54-d0d4-67b08dfb126d@redhat.com> On 10/16/2018 10:04 AM, Andrew Haley wrote: > On 10/16/2018 09:27 AM, Andrew Haley wrote: > >> I tested on a ThunderX2 machine with the LSE instruction set, and the >> jtreg tests all pass. I'll do a jcstress test on that box too, just to >> be sure. > > I see failures here: > > [FAILED] o.o.j.t.atomicity.varHandles.fields.GetAndSetTest.GetAndSetByte > (fork: #1, iteration #0, JVM args: [-XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]) > Observed state Occurrences Expectation Interpretation > 0, -1, 2 5,588 ACCEPTABLE actor1 execute before actor2 > 0, 0, -1 0 FORBIDDEN This won't happen because getAndSet is atomic > 0, 0, 2 0 FORBIDDEN This won't happen because getAndSet is atomic > 0, 2, 2 322,083 FORBIDDEN No default case provided, assume FORBIDDEN > 2, 0, -1 0 ACCEPTABLE actor1 execute after actor2 > > Once the entire jcstress run is complete I'll have a look to see what > is wrong. I found the bug: we also should fix the comparison instruction in the LSE code. I have a fix. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Oct 16 17:02:55 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Oct 2018 18:02:55 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> Message-ID: <29ccec40-4b15-17cd-7fbb-5c5b777e3926@redhat.com> On 10/16/2018 09:27 AM, Andrew Haley wrote: > On 10/15/2018 04:57 PM, Andrew Haley wrote: >> Andrew Dinn wrote: >> >>> I didn't eyeball the code (there's a lot to check!). I extended tests to >>> cover all combination of atomic operations/argument types. So at least, >>> tests should guarantee that the right variant in the ad file is >>> picked. Then, of course, all variants must be correctly implemented. For >>> that, I checked a couple times that the right boolean flag was passed. > > I tested on a ThunderX2 machine with the LSE instruction set, and the > jtreg tests all pass. I'll do a jcstress test on that box too, just to > be sure. This is what we need for LSE. I'm running jcstress again. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- diff -r c64384f414bc src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Wed Oct 10 23:05:15 2018 +0200 +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Tue Oct 16 12:57:56 2018 -0400 @@ -2367,21 +2367,18 @@ bool weak, Register result) { if (result == noreg) result = rscratch1; + BLOCK_COMMENT("cmpxchg {"); if (UseLSE) { mov(result, expected); lse_cas(result, new_val, addr, size, acquire, release, /*not_pair*/ true); - cmp(result, expected); + compare_eq(result, expected, size); } else { - BLOCK_COMMENT("cmpxchg {"); Label retry_load, done; if ((VM_Version::features() & VM_Version::CPU_STXR_PREFETCH)) prfm(Address(addr), PSTL1STRM); bind(retry_load); load_exclusive(result, addr, size, acquire); - if (size == xword) - cmp(result, expected); - else - cmpw(result, expected); + compare_eq(result, expected, size); br(Assembler::NE, done); store_exclusive(rscratch1, new_val, addr, size, release); if (weak) { @@ -2390,9 +2387,27 @@ cbnzw(rscratch1, retry_load); } bind(done); - BLOCK_COMMENT("} cmpxchg"); } -} + BLOCK_COMMENT("} cmpxchg"); +} + +// A generic comparison. Only compares for equality, clobbers rscratch1. +void MacroAssembler::compare_eq(Register rm, Register rn, enum operand_size size) { + if (size == xword) { + cmp(rm, rn); + } else if (size == word) { + cmpw(rm, rn); + } else if (size == halfword) { + eorw(rscratch1, rm, rn); + ands(zr, rscratch1, 0xffff); + } else if (size == byte) { + eorw(rscratch1, rm, rn); + ands(zr, rscratch1, 0xff); + } else { + ShouldNotReachHere(); + } +} + static bool different(Register a, RegisterOrConstant b, Register c) { if (b.is_constant()) diff -r c64384f414bc src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Wed Oct 10 23:05:15 2018 +0200 +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Tue Oct 16 12:57:56 2018 -0400 @@ -1020,7 +1020,10 @@ enum operand_size size, bool acquire, bool release, bool weak, Register result); +private: + void compare_eq(Register rn, Register rm, enum operand_size size); +public: // Calls address trampoline_call(Address entry, CodeBuffer *cbuf = NULL); From aph at redhat.com Thu Oct 18 08:09:43 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Oct 2018 09:09:43 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <29ccec40-4b15-17cd-7fbb-5c5b777e3926@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> <29ccec40-4b15-17cd-7fbb-5c5b777e3926@redhat.com> Message-ID: On 10/16/2018 06:02 PM, Andrew Haley wrote: > This is what we need for LSE. I'm running jcstress again. It's fine now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Thu Oct 18 08:14:04 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 18 Oct 2018 10:14:04 +0200 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <29ccec40-4b15-17cd-7fbb-5c5b777e3926@redhat.com> References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> <29ccec40-4b15-17cd-7fbb-5c5b777e3926@redhat.com> Message-ID: > This is what we need for LSE. I'm running jcstress again. Thanks for the patch. So this one fixes 8211320 (Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value) and not this one (barrier elision), right? Roland. From aph at redhat.com Thu Oct 18 08:41:58 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Oct 2018 09:41:58 +0100 Subject: [aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <58861670-3ed6-3954-8b66-0f51efac38c7@redhat.com> <40c3af18-1899-9c3e-f2ec-9013aa97d6d4@redhat.com> <2d15d28b-3bf7-149c-d6ca-ac199c50d246@redhat.com> <29ccec40-4b15-17cd-7fbb-5c5b777e3926@redhat.com> Message-ID: <3c9465cb-9a2b-e727-2fb2-4a9df439cde9@redhat.com> On 10/18/2018 09:14 AM, Roland Westrelin wrote: > Thanks for the patch. So this one fixes 8211320 (Aarch64: > unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics > broken with negative expected value) and not this one (barrier elision), > right? Yes. I'm sorry to get this wrong again: I'm running the tests with both patches applied. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu Oct 18 12:45:35 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 18 Oct 2018 13:45:35 +0100 Subject: [aarch64-port-dev ] [RFR] 8u191 Update Message-ID: Andrew Hughes Wed 25 Jul, 15:53 to aarch64-port-dev Hi, OpenJDK 8 was recently updated with a security update, u181. Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u181-b14. http://cr.openjdk.java.net/~andrew/shenandoah-8/u191/ Changes in aarch64-shenandoah-jdk8u181-b16 - Fix code differences against shenandoah/jdk8u Changes in aarch64-shenandoah-jdk8u191-b10 - S8049834: Two security tools tests do not run with only JRE - S8074462: Handshake messages can be strictly ordered - S8130132: jarsigner should emit warning if weak algorithms or keysizes are used - S8142927: Feed some text to STDIN in ProcessTools.executeProcess() - S8146115: Improve docker container detection and resource configuration usage - S8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh failing - S8152974: AWT hang occurrs when sequenced events arrive out of sequence - S8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out - S8164480: Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same - S8168628: (fc) SIGBUS when extending file size to map it - S8171452: (ch) linux io_util_md: Operation not supported exception after 8168628 - S8172529: Use PKIXValidator in jarsigner - S8180289: jarsigner treats timestamped signed jar invalid after the signer cert expires - S8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration - S8190674: sun/security/tools/jarsigner/TimestampCheck.java failed with java.nio.file.NoSuchFileException: ts2.cert - S8193892: Impact of noncloneable MessageDigest implementation - S8194534: Manifest better support - S8194546: Choosier FileManagers - S8195868: Address Internet Addresses - S8195874: Improve jar specification adherence - S8196663: [TESTBUG] test/compiler/loopopts/TestCMovSplitThruPhi.java fails on 32 bit Java - S8196897: Improve PRNG support - S8196902: Better HTTP redirection support - S8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue - S8199177: Enhance JNDI lookups - S8199226: Improve field accesses - S8201756: Improve cipher inputs - S8202478: Backout JDK-8152974 - S8202613: Improve TLS connections stability - S8202936: Improve script engine support - S8203654: Improve cypher state updates - S8204497: Better formatting of decimals - S8204667: Resources not freed on exception - S8205361: Better RIFF reading support - S8207336: Build failure in JDK8u on Windows after fix 8207260 - S8208350: Disable all DES cipher suites - S8208353: Upgrade JDK 8u to libpng 1.6.35 - S8208660: JDK 8u191 l10n resource file update - S8208754: The fix for JDK-8194534 needs updates Changes in aarch64-shenandoah-jdk8u191-b12 - S8207838: AArch64: Float registers incorrectly restored in JNI call - S8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls - S8211107: LDAPS communication failure with jdk 1.8.0_181 - S8211731: Reconsider default option for ClassPathURLCheck change done in JDK-8195874 [8207838 & 8210064 are already in the upstream repository, and were merged with the 8u191 update for b12] Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Oct 18 12:46:40 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 18 Oct 2018 13:46:40 +0100 Subject: [aarch64-port-dev ] [RFR] 8u191 Update In-Reply-To: References: Message-ID: On Thu, 18 Oct 2018 at 13:45, Andrew Hughes wrote: > > Andrew Hughes > > Wed 25 Jul, 15:53 > > > to aarch64-port-dev > Hi, > > OpenJDK 8 was recently updated with a security update, u181. > > Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u181-b14. > Ugh. Correction. This is u191 and aarch64-shenandoah-jdk8u191-b12. Copy and paste error :( -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From Pengfei.Li at arm.com Fri Oct 19 02:27:12 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 19 Oct 2018 02:27:12 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics Message-ID: Hi, I would like to enable intrinsics of floating-point Math.min/max methods on AArch64. Could anyone help review this change? Webrev: http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8212043 Below is the description of Math.max(double,double) in Java API doc. Behaviors of the other 3 methods are similar. "Returns the greater of two double values. That is, the result is the argument closer to positive infinity. If the arguments have the same value, the result is that same value. If either value is NaN, then the result is NaN. Unlike the numerical comparison operators, this method considers negative zero to be strictly smaller than positive zero. If one argument is positive zero and the other negative zero, the result is positive zero." [1] In AArch64 floating-point instruction set, the fmax instruction[2] has exactly the same behavior to the API description above. So these min/max calculations can be done in one single instruction. I also added a jtreg case[3] in this change to test these special arguments, including +0.0, -0.0, +inf, -inf and NaN. I ran the full jtreg test and no new issues were found. As I'm not familiar with other ISAs, intrinsics are enabled only on AArch64 in this change. I hope someone else can enable them on other platforms, if possible. [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Math.html#max(double,double) [2] https://developer.arm.com/docs/dui0801/latest/a64-floating-point-instructions/fmax-scalar [3] http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.00/test/hotspot/jtreg/compiler/intrinsics/math/TestFpMinMaxIntrinsics.java.html -- Thanks, Pengfei From aph at redhat.com Fri Oct 19 08:12:12 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Oct 2018 09:12:12 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: Message-ID: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> On 10/19/2018 03:27 AM, Pengfei Li (Arm Technology China) wrote: > > I would like to enable intrinsics of floating-point Math.min/max methods on AArch64. Could anyone help review this change? > Webrev: http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8212043 Thanks for this. It looks right, but I'd like to see JMH test results. Also, do we need an intrinsic? What happens to the performance if you try to match a pattern such as (a <= b) ? a : b ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Fri Oct 19 08:38:46 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 19 Oct 2018 10:38:46 +0200 Subject: [aarch64-port-dev ] [RFR] 8u191 Update In-Reply-To: References: Message-ID: <649ac81a-3d2c-70fd-2f6b-6b1d9a22474f@redhat.com> On 10/18/2018 02:45 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u191/ These look fine to me. -Aleksey From aph at redhat.com Fri Oct 19 08:53:48 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Oct 2018 09:53:48 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> Message-ID: On 10/19/2018 09:12 AM, Andrew Haley wrote: > Also, do we need an intrinsic? What happens to the performance if > you try to match a pattern such as > > (a <= b) ? a : b Ah, this would be wrong to covert to the min instruction because of NaN handling, wouldn't it? Forget that idea, then. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Fri Oct 19 09:57:13 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 19 Oct 2018 09:57:13 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> Message-ID: Hi Andrew, > Thanks for this. It looks right, but I'd like to see JMH test results. Here is a small JMH case to test the performance gain. Code can be found at http://cr.openjdk.java.net/~pli/rfr/8212043/TestFpMinMaxIntrinsics.java Please see below table for test results (JMH avg. score) on different servers when the intrinsics are turned off/on. CPU -XX:-InlineMathNatives -XX:+InlineMathNatives E5-2660 (x86) 407.377 ops/s 391.917 ops/s softiron 157.661 ops/s 338.389 ops/s qdf2400 369.771 ops/s 863.014 ops/s thunderX 70.536 ops/s 164.009 ops/s thunderX2 145.814 ops/s 338.293 ops/s huawei-D02 173.471 ops/s 399.399 ops/s huawei-D05 168.032 ops/s 604.316 ops/s > > Also, do we need an intrinsic? What happens to the performance if you > > try to match a pattern such as > > > > (a <= b) ? a : b > > Ah, this would be wrong to covert to the min instruction because of NaN > handling, wouldn't it? Forget that idea, then. Thanks. Yes, because of the NaN handling, this kind of patterns cannot be done with fmax/fmin instructions. -- Thanks, Pengfei From aph at redhat.com Fri Oct 19 12:36:42 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Oct 2018 13:36:42 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> Message-ID: <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> On 10/19/2018 10:57 AM, Pengfei Li (Arm Technology China) wrote: > Hi Andrew, > >> Thanks for this. It looks right, but I'd like to see JMH test results. > Here is a small JMH case to test the performance gain. Code can be found at http://cr.openjdk.java.net/~pli/rfr/8212043/TestFpMinMaxIntrinsics.java That file is empty. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Fri Oct 19 13:52:10 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 19 Oct 2018 13:52:10 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> , <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> Message-ID: Sorry I did the JMH test in hurry today and I found problems in my previous test. As we are updating our test infrastructure in the lab and our test scripts are buggy, the machine configurations and test results above are totally wrong... Please ignore my previous results. We will test it again once our test infrastructure is back. >>> Thanks for this. It looks right, but I'd like to see JMH test results. >> Here is a small JMH case to test the performance gain. Code can be found at > http://cr.openjdk.java.net/~pli/rfr/8212043/TestFpMinMaxIntrinsics.java > > That file is empty. I have re-uploaded the file, please check it again. -- Thanks, Pengfei From aph at redhat.com Fri Oct 19 15:22:37 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Oct 2018 16:22:37 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> Message-ID: <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> On 10/19/2018 02:52 PM, Pengfei Li (Arm Technology China) wrote: > > Sorry I did the JMH test in hurry today and I found problems in my previous test. As we are updating our test infrastructure in the lab and our test scripts are buggy, the machine configurations and test results above are totally wrong... Please ignore my previous results. We will test it again once our test infrastructure is back. > >>>> Thanks for this. It looks right, but I'd like to see JMH test results. >>> Here is a small JMH case to test the performance gain. Code can be found at >> http://cr.openjdk.java.net/~pli/rfr/8212043/TestFpMinMaxIntrinsics.java >> >> That file is empty. > I have re-uploaded the file, please check it again. Thanks. Putting code we're not licencsed to use on cr.openjdk is a bit pointless: /* * Copyright (c) 2018, Arm Limited and affiliates. * All rights reserved. */ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Oct 22 00:47:27 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:47:27 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <201810220047.w9M0lRDS013750@aojmv0008.oracle.com> Changeset: ecfad3b1de5e Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/ecfad3b1de5e Added tag aarch64-shenandoah-jdk8u181-b16 for changeset 465f1a149e91 ! .hgtags Changeset: b78fee92e8c2 Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/b78fee92e8c2 Added tag aarch64-shenandoah-jdk8u191-b10 for changeset ecfad3b1de5e ! .hgtags Changeset: adfade8a4d68 Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/adfade8a4d68 Added tag aarch64-shenandoah-jdk8u191-b12 for changeset b78fee92e8c2 ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:47:34 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:47:34 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <201810220047.w9M0lYH8013870@aojmv0008.oracle.com> Changeset: 0d9779b94be4 Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/0d9779b94be4 Added tag aarch64-shenandoah-jdk8u181-b16 for changeset 79f802c16d2d ! .hgtags Changeset: 74082d7096b4 Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/74082d7096b4 Added tag aarch64-shenandoah-jdk8u191-b10 for changeset 0d9779b94be4 ! .hgtags Changeset: 41c46cb99eed Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/41c46cb99eed Added tag aarch64-shenandoah-jdk8u191-b12 for changeset 74082d7096b4 ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:47:42 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:47:42 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 4 new changesets Message-ID: <201810220047.w9M0lgsh013949@aojmv0008.oracle.com> Changeset: 0575ff1d3ef7 Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/0575ff1d3ef7 Added tag aarch64-shenandoah-jdk8u181-b16 for changeset 3785fc91e325 ! .hgtags Changeset: cf757c072822 Author: aefimov Date: 2018-06-21 15:37 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/cf757c072822 8204497: Better formatting of decimals Reviewed-by: joehw ! src/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java Changeset: 9e28e477b70f Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/9e28e477b70f Added tag aarch64-shenandoah-jdk8u191-b10 for changeset cf757c072822 ! .hgtags Changeset: 6127bb2d19c2 Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/6127bb2d19c2 Added tag aarch64-shenandoah-jdk8u191-b12 for changeset 9e28e477b70f ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:47:49 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:47:49 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 3 new changesets Message-ID: <201810220047.w9M0ln0f014012@aojmv0008.oracle.com> Changeset: 481c4a15e7cc Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/481c4a15e7cc Added tag aarch64-shenandoah-jdk8u181-b16 for changeset c68865c20c47 ! .hgtags Changeset: 68a76a6c0450 Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/68a76a6c0450 Added tag aarch64-shenandoah-jdk8u191-b10 for changeset 481c4a15e7cc ! .hgtags Changeset: 2e06e21bed8f Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/2e06e21bed8f Added tag aarch64-shenandoah-jdk8u191-b12 for changeset 68a76a6c0450 ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:47:56 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:47:56 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 3 new changesets Message-ID: <201810220047.w9M0lude014076@aojmv0008.oracle.com> Changeset: f2344576b4c3 Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/f2344576b4c3 Added tag aarch64-shenandoah-jdk8u181-b16 for changeset e3c6e09b6571 ! .hgtags Changeset: fad784780153 Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/fad784780153 Added tag aarch64-shenandoah-jdk8u191-b10 for changeset f2344576b4c3 ! .hgtags Changeset: 129080f6a721 Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/129080f6a721 Added tag aarch64-shenandoah-jdk8u191-b12 for changeset fad784780153 ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:48:04 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:48:04 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 9 new changesets Message-ID: <201810220048.w9M0m54J014190@aojmv0008.oracle.com> Changeset: 2e87904a2274 Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2e87904a2274 Added tag aarch64-shenandoah-jdk8u181-b16 for changeset 67c63384e5e9 ! .hgtags Changeset: 9e41b3b8bf3c Author: hseigel Date: 2018-05-14 09:16 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9e41b3b8bf3c 8199226: Improve field accesses Reviewed-by: acorn, ahgross, rhalade Contributed-by: harold.seigel at oracle.com ! src/share/vm/interpreter/linkResolver.cpp Changeset: f27ab13215db Author: poonam Date: 2018-07-06 18:50 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f27ab13215db 8146115: Improve docker container detection and resource configuration usage Reviewed-by: bobv, dbuck ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp + src/os/linux/vm/osContainer_linux.cpp + src/os/linux/vm/osContainer_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: a3cde9d5a497 Author: shshahma Date: 2018-09-29 02:45 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a3cde9d5a497 8164480: Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same Summary: Exception checking code needs to handle pre-allocated exceptions. Reviewed-by: thartmann, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 1abda3fd4c15 Author: vaibhav Date: 2018-07-26 06:16 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1abda3fd4c15 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration Summary: Created tests for the feature Reviewed-by: mseledtsov ! src/share/vm/prims/whitebox.cpp + test/runtime/containers/docker/AttemptOOM.java + test/runtime/containers/docker/CPUSetsReader.java + test/runtime/containers/docker/CheckContainerized.java + test/runtime/containers/docker/DockerBasicTest.java + test/runtime/containers/docker/Dockerfile-BasicTest + test/runtime/containers/docker/Dockerfile-BasicTest-aarch64 + test/runtime/containers/docker/Dockerfile-BasicTest-ppc64le + test/runtime/containers/docker/Dockerfile-BasicTest-s390x + test/runtime/containers/docker/HelloDocker.java + test/runtime/containers/docker/PrintContainerInfo.java + test/runtime/containers/docker/TEST.properties + test/runtime/containers/docker/TestCPUAwareness.java + test/runtime/containers/docker/TestCPUSets.java + test/runtime/containers/docker/TestMemoryAwareness.java + test/runtime/containers/docker/TestMisc.java ! test/testlibrary/ClassFileInstaller.java + test/testlibrary/com/oracle/java/testlibrary/Common.java + test/testlibrary/com/oracle/java/testlibrary/DockerRunOptions.java + test/testlibrary/com/oracle/java/testlibrary/DockerTestUtils.java ! test/testlibrary/com/oracle/java/testlibrary/Platform.java ! test/testlibrary/com/oracle/java/testlibrary/Utils.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: c312a55969eb Author: bgopularam Date: 2018-02-06 22:11 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c312a55969eb 8196663: [TESTBUG] test/compiler/loopopts/TestCMovSplitThruPhi.java fails on 32 bit Java Reviewed-by: kvn Contributed-by: vaibhav.x.choudhary at oracle.com ! test/compiler/loopopts/TestCMovSplitThruPhi.java Changeset: 0d98b9f8dff3 Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0d98b9f8dff3 Added tag aarch64-shenandoah-jdk8u191-b10 for changeset c312a55969eb ! .hgtags Changeset: cefe63001e99 Author: andrew Date: 2018-10-09 08:03 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cefe63001e99 Sync with upstream - test/compiler/floatingpoint/TestFloatJNIArgs.java - test/compiler/floatingpoint/TestFloatJNIArgs.sh - test/compiler/floatingpoint/libTestFloatJNIArgs.c Changeset: fd7a9f17fc53 Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fd7a9f17fc53 Added tag aarch64-shenandoah-jdk8u191-b12 for changeset cefe63001e99 ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:48:16 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:48:16 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 36 new changesets Message-ID: <201810220048.w9M0mHVi014273@aojmv0008.oracle.com> Changeset: d740e9ae3286 Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d740e9ae3286 Added tag aarch64-shenandoah-jdk8u181-b16 for changeset 513d3f8a2b9c ! .hgtags Changeset: c8d92612fa9e Author: igerasim Date: 2018-04-18 22:35 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c8d92612fa9e 8194534: Manifest better support Reviewed-by: mchung, igerasim ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java Changeset: e0e4457e1712 Author: kaddepalli Date: 2018-07-13 11:22 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e0e4457e1712 8194546: Choosier FileManagers Reviewed-by: prr, serb, skoivu, rhalade ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: 5f633a4494e5 Author: igerasim Date: 2018-03-24 20:21 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/5f633a4494e5 8195868: Address Internet Addresses Reviewed-by: chegar, rriggs, igerasim, skoivu, rhalade ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetworkInterface.java ! src/solaris/native/java/net/NetworkInterface.c Changeset: d7dfe140a09b Author: igerasim Date: 2018-06-07 15:00 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d7dfe140a09b 8195874: Improve jar specification adherence Summary: Also reviewed by Chris Ries Reviewed-by: alanb, mchung, rriggs ! src/share/classes/sun/misc/URLClassPath.java Changeset: bfcfb9485c7e Author: igerasim Date: 2018-04-10 00:56 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/bfcfb9485c7e 8196897: Improve PRNG support Reviewed-by: weijun ! src/windows/native/sun/security/mscapi/security.cpp Changeset: ebc89036cd3e Author: robm Date: 2018-07-18 16:37 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ebc89036cd3e 8196902: Better HTTP redirection support Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: f49f73decac9 Author: robm Date: 2018-07-10 16:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f49f73decac9 8199177: Enhance JNDI lookups Reviewed-by: vtewari ! src/share/classes/com/sun/naming/internal/VersionHelper12.java Changeset: 00bff917d141 Author: apetcher Date: 2018-04-23 12:01 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/00bff917d141 8201756: Improve cipher inputs Summary: Clarify spec of CipherInputStream in Javadoc comments Reviewed-by: ascarpino ! src/share/classes/javax/crypto/CipherInputStream.java Changeset: c4c0f6b43de3 Author: igerasim Date: 2018-06-14 15:32 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c4c0f6b43de3 8202613: Improve TLS connections stability Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: 2dce1d6077ad Author: igerasim Date: 2018-06-19 10:56 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2dce1d6077ad 8203654: Improve cypher state updates Reviewed-by: ascarpino ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java Changeset: 017e867a9c14 Author: serb Date: 2018-07-10 16:20 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/017e867a9c14 8205361: Better RIFF reading support Reviewed-by: prr, rhalade, mschoene ! src/share/classes/com/sun/media/sound/DLSSoundbank.java ! src/share/classes/com/sun/media/sound/RIFFReader.java Changeset: e41f87ad6dd4 Author: igerasim Date: 2018-01-17 17:39 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e41f87ad6dd4 8049834: Two security tools tests do not run with only JRE Reviewed-by: mullan + test/sun/security/tools/jarsigner/weaksize.sh Changeset: 43b11aac837d Author: pkoppula Date: 2018-07-12 14:13 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/43b11aac837d 8074462: Handshake messages can be strictly ordered Reviewed-by: xuelei Contributed-by: prasadarao.koppula at oracle.com, sean.coffey at oracle.com ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java + src/share/classes/sun/security/ssl/HandshakeStateManager.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java Changeset: 9639a54b2b8a Author: igerasim Date: 2018-01-17 17:41 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9639a54b2b8a 8130132: jarsigner should emit warning if weak algorithms or keysizes are used Reviewed-by: mullan ! src/share/classes/sun/security/tools/KeyStoreUtil.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/tools/keytool/Main.java ! test/sun/security/tools/jarsigner/TsacertOptionTest.java + test/sun/security/tools/jarsigner/Warning.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ec.sh ! test/sun/security/tools/jarsigner/onlymanifest.sh - test/sun/security/tools/jarsigner/warnings.sh ! test/sun/security/tools/jarsigner/weaksize.sh Changeset: 02c6fac4aba9 Author: igerasim Date: 2018-01-17 17:38 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/02c6fac4aba9 8142927: Feed some text to STDIN in ProcessTools.executeProcess() Reviewed-by: rriggs ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java Changeset: 641e6dc40da7 Author: igerasim Date: 2018-01-17 17:42 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/641e6dc40da7 8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh failing Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 3de1ba62099a Author: kaddepalli Date: 2018-04-12 12:35 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3de1ba62099a 8152974: AWT hang occurrs when sequenced events arrive out of sequence Reviewed-by: serb, prr, ssadetsky ! src/share/classes/java/awt/SequencedEvent.java + test/java/awt/event/SequencedEvent/SequencedEventTest.java Changeset: e6c248363136 Author: igerasim Date: 2018-01-17 17:43 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e6c248363136 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: a01025118dc1 Author: dbuck Date: 2018-02-06 03:50 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a01025118dc1 8168628: (fc) SIGBUS when extending file size to map it 8171452: (ch) linux io_util_md: Operation not supported exception after 8168628 Reviewed-by: alanb, bpb ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/FileDispatcher.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java + test/java/nio/channels/FileChannel/FileExtensionAndMap.java Changeset: 37b907f2c44c Author: igerasim Date: 2018-01-17 17:45 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/37b907f2c44c 8172529: Use PKIXValidator in jarsigner Reviewed-by: xuelei, mullan, alanb ! src/share/classes/sun/security/tools/jarsigner/Main.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 75cf08f9fb33 Author: igerasim Date: 2018-01-17 17:46 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/75cf08f9fb33 8180289: jarsigner treats timestamped signed jar invalid after the signer cert expires Reviewed-by: mullan ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/lib/testlibrary/jdk/testlibrary/SecurityTools.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/Warning.java ! test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/warnings/Test.java ! test/sun/security/tools/jarsigner/weaksize.sh Changeset: a0c2fc016601 Author: igerasim Date: 2018-01-17 17:47 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a0c2fc016601 8190674: sun/security/tools/jarsigner/TimestampCheck.java failed with java.nio.file.NoSuchFileException: ts2.cert Reviewed-by: mullan ! test/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 4ba42f25822a Author: coffeys Date: 2018-03-06 18:29 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4ba42f25822a 8193892: Impact of noncloneable MessageDigest implementation Reviewed-by: wetmore + test/sun/security/ssl/HandshakeHash/DigestBase.java + test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java + test/sun/security/ssl/HandshakeHash/MyProvider.java Changeset: 7b56edf7941a Author: weijun Date: 2018-02-26 08:30 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7b56edf7941a 8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue Reviewed-by: coffeys, xuelei ! src/share/classes/sun/security/krb5/internal/rcache/AuthList.java ! src/share/classes/sun/security/krb5/internal/rcache/MemoryCache.java Changeset: 684036e3473b Author: dkumar Date: 2018-05-04 11:52 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/684036e3473b 8202478: Backout JDK-8152974 Reviewed-by: prr, serb ! src/share/classes/java/awt/SequencedEvent.java - test/java/awt/event/SequencedEvent/SequencedEventTest.java Changeset: 6f94f48e7e59 Author: igerasim Date: 2018-06-21 10:08 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6f94f48e7e59 8204667: Resources not freed on exception Reviewed-by: skoivu, chegar ! src/solaris/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: 9c1309cde479 Author: kaddepalli Date: 2018-07-16 13:10 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9c1309cde479 8207336: Build failure in JDK8u on Windows after fix 8207260 Reviewed-by: prr ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java Changeset: 3805d7b5202b Author: pkoppula Date: 2018-08-28 19:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3805d7b5202b 8208350: Disable all DES cipher suites Reviewed-by: mullan, jnimeh, coffeys ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/sun/security/krb5/auto/UnboundSSL.java ! test/sun/security/krb5/auto/UnboundSSLMultipleKeys.java ! test/sun/security/krb5/auto/UnboundSSLPrincipalProperty.java ! test/sun/security/krb5/auto/unbound.ssl.policy + test/sun/security/ssl/CipherSuite/NoDesRC4CiphSuite.java Changeset: 545a164ec2fd Author: prr Date: 2018-08-01 11:16 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/545a164ec2fd 8208353: Upgrade JDK 8u to libpng 1.6.35 Reviewed-by: serb, jdv ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h ! src/share/native/sun/awt/libpng/pngerror.c ! src/share/native/sun/awt/libpng/pngget.c ! src/share/native/sun/awt/libpng/pnginfo.h ! src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngpread.c ! src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c ! src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtrans.c Changeset: b2ff15dab72f Author: ljiang Date: 2018-08-08 01:46 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b2ff15dab72f 8208660: JDK 8u191 l10n resource file update Reviewed-by: coffeys ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java Changeset: 6988c76867e0 Author: igerasim Date: 2018-08-08 00:32 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6988c76867e0 8208754: The fix for JDK-8194534 needs updates Reviewed-by: alanb, igerasim, rhalade, mullan ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 30cdef79fac8 Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/30cdef79fac8 Added tag aarch64-shenandoah-jdk8u191-b10 for changeset 6988c76867e0 ! .hgtags Changeset: 3a7fa141928f Author: pkoppula Date: 2018-10-02 21:38 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3a7fa141928f 8211107: LDAPS communication failure with jdk 1.8.0_181 Reviewed-by: chegar, coffeys, vtewari ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: e9f38f4d9e59 Author: igerasim Date: 2018-10-09 08:09 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e9f38f4d9e59 8211731: Reconsider default option for ClassPathURLCheck change done in JDK-8195874 ! src/share/classes/sun/misc/URLClassPath.java Changeset: 70a423caee44 Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/70a423caee44 Added tag aarch64-shenandoah-jdk8u191-b12 for changeset e9f38f4d9e59 ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:48:24 2018 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 22 Oct 2018 00:48:24 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 4 new changesets Message-ID: <201810220048.w9M0mOjA014346@aojmv0008.oracle.com> Changeset: bbd8d2f53034 Author: andrew Date: 2018-09-28 23:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/bbd8d2f53034 Added tag aarch64-shenandoah-jdk8u181-b16 for changeset afa3430ceb4a ! .hgtags Changeset: 6ac874f83812 Author: rpatil Date: 2018-06-19 14:48 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/6ac874f83812 8202936: Improve script engine support Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/Global.java Changeset: 5f54510f97fb Author: andrew Date: 2018-10-01 13:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/5f54510f97fb Added tag aarch64-shenandoah-jdk8u191-b10 for changeset 6ac874f83812 ! .hgtags Changeset: 54190ba22e92 Author: andrew Date: 2018-10-09 08:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/54190ba22e92 Added tag aarch64-shenandoah-jdk8u191-b12 for changeset 5f54510f97fb ! .hgtags From gnu.andrew at redhat.com Mon Oct 22 00:48:32 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 22 Oct 2018 01:48:32 +0100 Subject: [aarch64-port-dev ] [RFR] 8u191 Update In-Reply-To: <649ac81a-3d2c-70fd-2f6b-6b1d9a22474f@redhat.com> References: <649ac81a-3d2c-70fd-2f6b-6b1d9a22474f@redhat.com> Message-ID: On Fri, 19 Oct 2018 at 09:38, Aleksey Shipilev wrote: > > On 10/18/2018 02:45 PM, Andrew Hughes wrote: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u191/ > > These look fine to me. > > -Aleksey > Thanks. Pushed. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From Pengfei.Li at arm.com Mon Oct 22 02:40:58 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 22 Oct 2018 02:40:58 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> Message-ID: Hi Andrew, > Thanks. Putting code we're not licencsed to use on cr.openjdk is a bit > pointless: Thanks for pointing out. I've updated this file. http://cr.openjdk.java.net/~pli/rfr/8212043/TestFpMinMaxIntrinsics.java I re-tested this JMH code manually on an AArch64 server just now. The findFmin() and findFmax() items do not have much performance gain (1.1x - 1.2x). But the findDmin() and findDmax() items are optimized a lot (about 29x - 30x). I don't understand why float and double differ so greatly. Maybe you could try it in your machine and see if it's the similar result. -- Thanks, Pengfei From aph at redhat.com Mon Oct 22 17:07:15 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Oct 2018 18:07:15 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> Message-ID: <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> On 10/22/2018 03:40 AM, Pengfei Li (Arm Technology China) wrote: > I re-tested this JMH code manually on an AArch64 server just now. > The findFmin() and findFmax() items do not have much performance > gain (1.1x - 1.2x). But the findDmin() and findDmax() items are > optimized a lot (about 29x - 30x). I don't understand why float and > double differ so greatly. Maybe you could try it in your machine and > see if it's the similar result. Writing jmh benchmarks can be really difficult. C2 is an extremely clever compiler so you need to confuse it so totally that it does not completely optimize away your benchmark. I have rewritten your benchmark with that in mind; please find it at http://cr.openjdk.java.net/~aph/8212043/TestFpMinMaxIntrinsics.java Before: Benchmark Mode Cnt Score Error Units TestFpMinMaxIntrinsics.findDmax avgt 3 9.626 ? 0.037 us/op TestFpMinMaxIntrinsics.findDmin avgt 3 9.688 ? 0.043 us/op TestFpMinMaxIntrinsics.findFmax avgt 3 9.351 ? 0.357 us/op TestFpMinMaxIntrinsics.findFmin avgt 3 9.483 ? 2.770 us/op After: Benchmark Mode Cnt Score Error Units TestFpMinMaxIntrinsics.findDmax avgt 3 5.384 ? 0.003 us/op TestFpMinMaxIntrinsics.findDmin avgt 3 5.382 ? 0.004 us/op TestFpMinMaxIntrinsics.findFmax avgt 3 5.383 ? 0.005 us/op TestFpMinMaxIntrinsics.findFmin avgt 3 5.384 ? 0.028 us/op Please consider if there are any situations in which your intrinsics might make code slower. To see if this can happen I have written another benchmark. Here it is with -XX:-InlineMathNatives: Benchmark (shuffle) Mode Cnt Score Error Units TestFpMinMaxIntrinsics2.findFmin false avgt 3 4.251 ? 0.003 us/op and with -XX:+InlineMathNatives: Benchmark (shuffle) Mode Cnt Score Error Units TestFpMinMaxIntrinsics2.findFmin false avgt 3 5.375 ? 0.001 us/op The difference is the shuffle of the local variables. Is it likely to be a common case that C2 can determine from its branch statistics that a fast path can be highly optimized, and this visibility disappears when we have an intrinsic? Should we do anything about that? Please think also about constant propagation. This: @Benchmark public double constExpr() { double tmp = dnums[33]; for (int i = 1; i < SIZE; i++) { tmp = min(dnums[27], min(0.1, min(1.1, min(2.1, min(3.1, min(4.1, min(5.1, min(6.1, min(7.1, min(8.1, min(9.1, dnums[12]))))))))))); } return tmp; } } causes an Internal Error (/home/aph/jdk-jdk/src/hotspot/share/opto/phaseX.cpp:691) when I run it with your patch. I think you are not handling the case where both arguments are constant, and you need to do that. It might be sufficient simply to say if (a->is_Con() || b->is_Con()) { return false; } but maybe you want to be more ambitious. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dms at samersoff.net Tue Oct 23 08:36:48 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 23 Oct 2018 11:36:48 +0300 Subject: [aarch64-port-dev ] AARCH64 support for lworld In-Reply-To: <9b2ee9ae-6643-5cf7-00a2-c5a94a03a9f6@oracle.com> References: <9b2ee9ae-6643-5cf7-00a2-c5a94a03a9f6@oracle.com> Message-ID: <5d4decce-7c7d-ca4d-af41-ca6110fd723d@samersoff.net> Tobias, As soon as lw1 is out ... Is there a webrev of changes between lw1 and plain hotspot? -Dmitry On 03.09.2018 11:33, Tobias Hartmann wrote: > Hi Dmitry, > > we use the "repo-valhalla" affects and fix version for value type related bugs/enhancements, so it > would make sense if you create an enhancement in this category and also add the label "lworld". > > Great that you plan to port this work to Aarch64! > > Some background information from the JIT side: The current implementation should be platform > independent except for the calling convention changes. These are: > 1) Pass value types as fields (-XX:+ValueTypePassFieldsAsArgs) > 2) Return value types as fields (-XX:+ValueTypeReturnedAsFields) > 3) Special entry point for nullable value types (JDK-8209134) > > 1) and 2) are currently disabled and need to be reworked for value types. I plan to work on this in > the near future but you can safely ignore these for now (you will most likely get some build > failures due to interface changes though that you need to fix). 3) was added just recently with > (JDK-8209134) and should be straight forward to port. > > Here is a webrev of all the hotspot changes we did: > http://cr.openjdk.java.net/~thartmann/valhalla/hs_changes/ > > Unfortunately, it's very outdated but I will hopefully find some time to update it soon. > > Best regards, > Tobias > > On 03.09.2018 09:46, Dmitry Samersoff wrote: >> Hello Everybody, >> >> I started implementation of AARCH64 support for lworld. >> >> I'm on very early stage so any advices are highly appreciated. >> >> Should I file a CR for this task somewhere? What is correct way to do it? >> >> -Dmitry >> >> From tobias.hartmann at oracle.com Tue Oct 23 08:58:42 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 23 Oct 2018 10:58:42 +0200 Subject: [aarch64-port-dev ] AARCH64 support for lworld In-Reply-To: <5d4decce-7c7d-ca4d-af41-ca6110fd723d@samersoff.net> References: <9b2ee9ae-6643-5cf7-00a2-c5a94a03a9f6@oracle.com> <5d4decce-7c7d-ca4d-af41-ca6110fd723d@samersoff.net> Message-ID: Hi Dmitry, LW1 EA is already out for quite a while [1]. Here's a webrev of the changes from September: http://cr.openjdk.java.net/~thartmann/valhalla/hs_changes/ We are currently working on LW2, which will re-introduce Q-Types: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-October/000760.html Best regards, Tobias [1] https://jdk.java.net/valhalla/ On 23.10.18 10:36, Dmitry Samersoff wrote: > Tobias, > > As soon as lw1 is out ... > > Is there a webrev of changes between lw1 and plain hotspot? > > -Dmitry > > On 03.09.2018 11:33, Tobias Hartmann wrote: >> Hi Dmitry, >> >> we use the "repo-valhalla" affects and fix version for value type related bugs/enhancements, so it >> would make sense if you create an enhancement in this category and also add the label "lworld". >> >> Great that you plan to port this work to Aarch64! >> >> Some background information from the JIT side: The current implementation should be platform >> independent except for the calling convention changes. These are: >> 1) Pass value types as fields (-XX:+ValueTypePassFieldsAsArgs) >> 2) Return value types as fields (-XX:+ValueTypeReturnedAsFields) >> 3) Special entry point for nullable value types (JDK-8209134) >> >> 1) and 2) are currently disabled and need to be reworked for value types. I plan to work on this in >> the near future but you can safely ignore these for now (you will most likely get some build >> failures due to interface changes though that you need to fix). 3) was added just recently with >> (JDK-8209134) and should be straight forward to port. >> >> Here is a webrev of all the hotspot changes we did: >> http://cr.openjdk.java.net/~thartmann/valhalla/hs_changes/ >> >> Unfortunately, it's very outdated but I will hopefully find some time to update it soon. >> >> Best regards, >> Tobias >> >> On 03.09.2018 09:46, Dmitry Samersoff wrote: >>> Hello Everybody, >>> >>> I started implementation of AARCH64 support for lworld. >>> >>> I'm on very early stage so any advices are highly appreciated. >>> >>> Should I file a CR for this task somewhere? What is correct way to do it? >>> >>> -Dmitry >>> >>> From gary.adams at oracle.com Tue Oct 23 20:29:08 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 23 Oct 2018 16:29:08 -0400 Subject: [aarch64-port-dev ] SIGBUS on linux/aarch64 serviceability test HS202 - JDK-8209415 Message-ID: <1df533d2-0cbc-b88e-c2f9-f80a939080d2@oracle.com> A bug was reported for the HS202 serviceability test on a linux/aarch64 platform, but there have been no failures reported on other platforms. I'm afraid it will get lost if it is not properly labeled. Is there anyone who could confirm the problem still exists on the latest linux/aarch64 builds? Does the error look familiar? https://bugs.openjdk.java.net/browse/JDK-8209415 From aph at redhat.com Wed Oct 24 08:44:11 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Oct 2018 09:44:11 +0100 Subject: [aarch64-port-dev ] SIGBUS on linux/aarch64 serviceability test HS202 - JDK-8209415 In-Reply-To: <1df533d2-0cbc-b88e-c2f9-f80a939080d2@oracle.com> References: <1df533d2-0cbc-b88e-c2f9-f80a939080d2@oracle.com> Message-ID: <241e574b-a487-4e1c-12ae-5455f6dc5cc7@redhat.com> On 10/23/2018 09:29 PM, gary.adams at oracle.com wrote: > A bug was reported for the HS202 serviceability test > on a linux/aarch64 platform, but there have been no > failures reported on other platforms. I'm afraid it will get lost > if it is not properly labeled. > > Is there anyone who could confirm the problem still exists > on the latest linux/aarch64 builds? > > Does the error look familiar? > > https://bugs.openjdk.java.net/browse/JDK-8209415 No, I haven't seen it before. Thanks for the heads up. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Wed Oct 24 11:40:40 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 24 Oct 2018 13:40:40 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: <7e5f4ce4-0169-7eed-d6c6-c62fd3f85e10@redhat.com> References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> <7e5f4ce4-0169-7eed-d6c6-c62fd3f85e10@redhat.com> Message-ID: http://cr.openjdk.java.net/~roland/8211320/webrev.02/ A new webrev that includes Andrew Haley's patch from: http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-October/006444.html Good to push? Roland. From aph at redhat.com Wed Oct 24 12:29:50 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Oct 2018 13:29:50 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> <7e5f4ce4-0169-7eed-d6c6-c62fd3f85e10@redhat.com> Message-ID: On 10/24/2018 12:40 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8211320/webrev.02/ > > A new webrev that includes Andrew Haley's patch from: > > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-October/006444.html > > Good to push? Yes, that's great. Thank you for solving a problem that was vexing us for several years. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Wed Oct 24 13:54:29 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 24 Oct 2018 13:54:29 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> , <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> Message-ID: Hi Andrew, Thanks for your benchmark code. It's really helpful. > The difference is the shuffle of the local variables. Is it likely to > be a common case that C2 can determine from its branch statistics that > a fast path can be highly optimized, and this visibility disappears > when we have an intrinsic? Should we do anything about that? I analyzed the assembly code generated from your second benchmark. The consecutive Math.min/max calls are compiled to consecutive fcmp+branch instructions. Float numbers f0, f1, ... and f4 are loop invariants when shuffle is turned off. So the branch statistics are very much biased (to taken). That's really highly optimized. I also tested and consulted hardware guys on the performance between the fmin instruction and the combination of fcmp+branch. The fmin instruction is faster than the combination in common cases, although there are exceptions when branch is quite biased. So I guess using fmin/fmax may benefit most cases (please correct me if I'm wrong). And currently I have no ideas of how to bail out the intrinsics when this kind of exceptions occur. >?if (a->is_Con() || b->is_Con()) { >??? return false; >? } I added this code into my patch. I think it should be enough. Please see a new webrev with it: http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.01/ Thanks again for your careful review. Please let me know if you have some other suggestions. -- Thanks, Pengfei From adinn at redhat.com Wed Oct 24 15:50:01 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 24 Oct 2018 16:50:01 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value In-Reply-To: References: <7a28fd55-d8f8-c9ef-7f27-8db03a4aa49e@redhat.com> <8d472ebc-b14f-7927-a809-8c2165cfd603@redhat.com> <0b8db275-0460-7e95-b67a-a18a3237f5df@redhat.com> <2c0d35e3-6c47-1c89-6f8a-18d646abf0d9@redhat.com> <7e5f4ce4-0169-7eed-d6c6-c62fd3f85e10@redhat.com> Message-ID: <124abf8b-af47-6cce-92f5-7ee7315cf663@redhat.com> On 24/10/18 12:40, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8211320/webrev.02/ > > A new webrev that includes Andrew Haley's patch from: > > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-October/006444.html > > Good to push? Yes, this looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Thu Oct 25 10:31:16 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Oct 2018 11:31:16 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> Message-ID: <0abe597a-6fcc-a05c-4c5d-fb42d9ee0c1f@redhat.com> On 10/24/2018 02:54 PM, Pengfei Li (Arm Technology China) wrote: > Hi Andrew, > > Thanks for your benchmark code. It's really helpful. > >> The difference is the shuffle of the local variables. Is it likely to >> be a common case that C2 can determine from its branch statistics that >> a fast path can be highly optimized, and this visibility disappears >> when we have an intrinsic? Should we do anything about that? > > I analyzed the assembly code generated from your second > benchmark. The consecutive Math.min/max calls are compiled to > consecutive fcmp+branch instructions. Float numbers f0, f1, ... and > f4 are loop invariants when shuffle is turned off. So the branch > statistics are very much biased (to taken). That's really highly > optimized. Yes, it really is. How common is that? > I also tested and consulted hardware guys on the performance between > the fmin instruction and the combination of fcmp+branch. The fmin > instruction is faster than the combination in common cases, although > there are exceptions when branch is quite biased. It may be very common that branches are highly biased. The common serial algorithm for finding the minimum of an array is to keep a variable X which initially contains the largest possible number then perform the min() operation on X and every member of the array. How often does X actually change? In other words, how often is X larger than a[i] ? This benchmark provides an answer, but not necessarily the right one: @Benchmark public double arrayMin(BenchmarkState state ) { double tmp = Double.POSITIVE_INFINITY; for (int i = 1; i < SIZE; i++) { tmp = min(tmp, state.dnums[i]); } return tmp; } Before: Benchmark Mode Cnt Score Error Units TestFpMinMaxIntrinsics2.arrayMin avgt 3 0.819 ? 0.001 us/op After: Benchmark Mode Cnt Score Error Units TestFpMinMaxIntrinsics2.arrayMin avgt 3 0.771 ? 0.001 us/op Of course, there is still a possible problem: the data in the array are the same every time, so all the branches are perfectly predicted. It is possible to debias the benchmark by having two data arrays, one the reverse of the other: @Benchmark public double unbiasedArrayMin(BenchmarkState state ) { double tmp = Double.POSITIVE_INFINITY; double[] anArray = state.twoDNums[state.toggle & 1]; state.toggle++; for (int i = 0; i < anArray.length; i++) { tmp = min(tmp, anArray[i]); } return tmp; } but it makes little difference to the result. So, (probably) the commonest use of min() is faster with the intrinsic, but only just. Nevertheless I think this patch should go in because it can easily be vectorized, and that should be the next step. > So I guess using fmin/fmax may benefit most cases (please correct me > if I'm wrong). And currently I have no ideas of how to bail out the > intrinsics when this kind of exceptions occur. Yes, it's tricky. >> if (a->is_Con() || b->is_Con()) { >> return false; >> } > > I added this code into my patch. I think it should be enough. > Please see a new webrev with it: > http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.01/ > > Thanks again for your careful review. Please let me know if you have > some other suggestions. I have a sort-of meta-suggestion. Everyone should be hostile to their own patches: we all need to hate our own code! This sounds crazy, but it's true. When you write a patch, you should deliberately write test code which shows your patch at its very worst. And your benchmarks should measure the worst case performance of your optimization. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Fri Oct 26 10:36:23 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 26 Oct 2018 10:36:23 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <0abe597a-6fcc-a05c-4c5d-fb42d9ee0c1f@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> <0abe597a-6fcc-a05c-4c5d-fb42d9ee0c1f@redhat.com> Message-ID: Hi, > So, (probably) the commonest use of min() is faster with the intrinsic, but > only just. Nevertheless I think this patch should go in because it can easily be > vectorized, and that should be the next step. I got a reason why consecutive fmins are slower. The fmin sequence generated by the nested min() calls has RaW data dependencies. One fmin writes an fp register and the next fmin reads the same one. It leads the instruction pipeline to stall frequently. Anyway, thanks for your case which helps me understand this point. I guess we still need another reviewer to look at this patch since I modified the common part of code, although there should be no effect on other platforms. So, any other reviewers can help? http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.01/ > I have a sort-of meta-suggestion. Everyone should be hostile to their own > patches: we all need to hate our own code! This sounds crazy, but it's true. > When you write a patch, you should deliberately write test code which shows > your patch at its very worst. And your benchmarks should measure the worst > case performance of your optimization. I agree. This will be the most useful suggestion for my future work. -- Thanks, Pengfei From dmitrij.pochepko at bell-sw.com Fri Oct 26 12:21:36 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 26 Oct 2018 15:21:36 +0300 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <1b770596-8da2-74be-bad2-832bf4a6622a@redhat.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> <1b770596-8da2-74be-bad2-832bf4a6622a@redhat.com> Message-ID: <978ebf83-1c79-6310-c2ae-abc283552ce6@bell-sw.com> Hi Andrew, I prepared new patch with all your comments addressed. Changes: - fixed huge y case - updated scalbn block to use approach you suggested - updated optimized algorithm pseudo code to reflect all changes, also fixed few minor pseudo code issues - rearranged assembly code: -- renamed registers variables to have names correlating to C-code where applicable -- introduced local blocks with local labels and register mappings where applicable -- removed unnecessary register remappings -- moved odd/even check code generation to separate function -- removed K_IS_0 and K_IS_1 branches code repetition - added simple jtreg test Regarding testing: I found that one of tests I was using ( http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/lang/Math/PowTests.java) actually skip non-corner-case testing. Still, this test has very good set of input values, which can be re-used. I created enhancement for this test to actually test non-corner-case values ( https://bugs.openjdk.java.net/browse/JDK-8211002 ). I modified this test locally to have everything testing and it passed. I also slightly modified bruteforce test I've sent before to iterate through X values of range (0, 1E300) using ~10^8 ulps step with several Y values(tiny/normal/large/huge), which took several days to run. All seems fine. updated patch: http://cr.openjdk.java.net/~dpochepk/8189107/webrev.04 Thanks, Dmitrij On 21/09/2018 6:01 PM, Andrew Dinn wrote: > Hi Dmitrij, > > As promised here is the review (after sig) based on webrev.02. The > review first describes the problems I have identified. It then continues > with recommendations for (extensive) rework. Since it is based on > webrev.02 you will have to make some allowance for the changes you > introduced in your webrev.03 > > I have revised you webrev to include fixes for the two errors I > identified and a new version is available here > > http://cr.openjdk.java.net/~adinn/8189107/webrev.03/ > > The webrev includes my recommended fix for to the scalbn code in > macroAssembler_pow.cpp and a correction to the declaration of table > _pow_coef1 in stubRoutines_aarch64.cpp. I explain these changes below. > > I have also uploaded a commented version of the original algorithm and a > revised algorithm based on your code here > > http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt > http://cr.openjdk.java.net/~adinn/8189107/revised_algorithm.txt > > You have seen the original algorithm modulo a few tweaks that emerged in > creating the revised version. The revised algorithm /faithfully/ models > your webrev.02 code (with a couple of notable exceptions that relate to > problems described below). That faithful modelling of the code includes > retaining the order of computation of all values. In particular, it > models early computation of some data that you appear to have introduced > in order to pipeline certain operations. > > At the same time, the algorithm also introduces a much more coherent > control structure (inserting 'if then else' in place of GOTO everywhere > it is possible) and a nested /block structure/ (none of this required > reordering btw). It profits from this to introduce block local > declarations which scope the values computed and used at successive > steps. As far as possible the revised algorithm employs the same naming > convention as the original algorithm (I'll explain more on that in the > detailed feedback below). > > Why does this matter? Well, once the errors get fixed, by far the > biggest remaining problems with the existing code are 1) its unclear > control structure and 2) its incoherent allocation of data to registers. > The intention of providing block structure and block local use of > variables in the revised algorithm is to enable introduction of similar > block structuring and block local declarations for registers and branch > labels in the generator code. In particular, that will allow the > generator code to be rewritten to use symbolic names for registers > consistently throughout the function. > > So, a small number of register mappings for variables that are global to > the algorithm will need to be be retained at the start of the function. > However, they will use meaningful names like x, exp_mask, one_d, result > etc instead of the completely meaningless aliases, tm1, tmp2 etc, that > you provided. Similarly, some of the label declarations (mostly for exit > cases) will need to be retained at the top level. > > However, most register mappings will be for variables that are local to > a block. So, they will need to be declared at the start of that block > making it clear where they are used and where they are no longer in use. > Similarly most label declarations will be only need to be declared at > the start of the immediately enclosing block that generates the code > identified by the label. This will ensure declarations are close to > their point of use and are not in scope after they become redundant (or > at least not for very long). > > Register mappings for variables declared in an outer block that are live > across nested blocks will then be able to be used consistently in those > inner blocks while clearly identifying precisely what values are being > generated, used or updated. The same applies for label declarations. > They can be used as branch targets in nested blocks but will not be > visible in outer scopes or sibling scopes. > > Where possible the revised algorithm employs the same naming convention > as the original algorithm for the values it operates on -- with one > important modification. A suffix convention has been adopted to clarify > some ambiguities present in the original. For example, this allows us to > distinguish the double value x from its long bits representation x_r, > its 32 bit high word x_h or its 32 bit positive high word ix_h. The > algorithm also employs block local declarations to scope intermediate > values, employing names starting with 'tmp'. These are often introduced > in small, local blocks, allowing the same names tmp1, tmp2 etc to be > reused without ambiguity. > > So, I hope it is clear how you can use this algorithm to rewrite the > generator code to be much more readable and maintainable -- that being > the ultimate goal here. I'm not willing to let the code be committed > without this restructuring taking place. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > Problems > -------- > > 1) Error in Y_IS_HUGE case > > The vector maths that computes the polynomial for this case expects to > load the first 6 coefficients in table _pow_coef1 in the permuted order > (0.25, -ivln2, -0.333333333333, 0.5, ivln2_l, ivln2_h). However, the > table declaration in stubRoutines_aarch64.cpp declares them in the order > (-0.333333333333, 0.25, 0.5, -ivln2, ivln2_l, ivln2_h). > > 2) scalbn implementation is wrong > > The original code was using this algorithm > > 1 if (0 >= (j_h >> 20)) > 2 tmp1 = n' - 1023 // bias n as an exponent > 3 tmp2 = (tmp1 & 0x3ff) << 52 // install as high bits > 4 two_n_d = LONG_TO_DOUBLE(tmp2) > 5 z = z * two_n_d // rescale > 6 b(CHECK_RESULT_NEGATION); > > The problems are: > > line 1: as you spotted the test was wrongly implemented using cmp not > cmpw (j_h is computed using an int add so sign extending as a long fails > to retain the overflow bit). > > line 2: n is the unbiased exponent -- rebiasing it requires adding 1023, > not subtracting it > > line 3: when we hit underflow the unbiased exponent is in the range > [-1024, -1075]. So, after correcting the sub to an add the exponent in > tmp1 will be negative (that is precisely the case the if test looks > for). Installing the top 12 bits exponent of this negative value into > the high bits of a double gives a float with unbiased exponent in range > [970, 1023] i.e. a very high positive power of 2 rather than a very low > negative one. The result is by by about 300 orders of magnitude! > > line 6: As you spotted, the multiply here updates the register storing z > rather than installing the result in v0 > > I explain all this not to point out why it is wrong but to show how your > original version can be salvaged with a few small changes. Basically we > want to multiply z by 2^n to get the result where n lies between -1023 > and -1075. Depending on the values of z and n the result will be either > a subnormal double or +0. So, the simplest solution is to do the > multiply in two stages. Here is a revised algorithm: > > if (0 >= (j_h >> 20)) { > double two_n_r // power of 2 as long bits mapped to r2 > long biased_n // n' - 1023 mapped to r2 > double two_n_d // used to rescale z to underflow value > // mapped to v17 > // split the rescale into two steps: 2^-512 then the rest > n = n + 512 > two_n_r = 0x1ff << 52 // high bits for 2^-512 > two_n_d = LONG_TO_DOUBLE(two_n_r) > z' = z' * two_n_d > biased_n = n + 1023 // bias remainder -- will now be positive! > two_n_r = (biased_n & 0x3ff) << 52 // high bits for 2^n > two_n_d = LONG_TO_DOUBLE(two_n_r) > result = z' * two_n_d > } else { > ... > > The code for this is: > > cmpw(zr, tmp10, ASR, 20); > br(LT, NO_SCALBN); > // n = tmp1 > // rescale first by 2^-512 and then by the rest > addw(tmp1, tmp1, 512); // n -> n + 512 > movz(tmp2, 0x1FF0, 48); > fmovd(v17, tmp2); // 2^-512 > fmuld(v18, v18, v17); // z = z * 2^-512 > addw(tmp2, tmp1, 1023); // biased exponent > ubfm(tmp2, tmp2, 12, 10); > fmovd(v17, tmp2); // 2^n > fmuld(v0, v18, v17); // result = z * 2^n > b(CHECK_RESULT_NEGATION); > bind(NO_SCALBN); > . . . > > I think this is simpler than your alternative. I checked it on several > test cases and it agrees with the existing StrictMath code. > > 3) Use of Estrin form in place of Horner form > > I would prefer not to use this without a proof that the re-ordered > computation does not introduce rounding errors. I doubt that it will and > I suspect that even if it did the error will be very small, certainly > small enough that the leeway between what is expected of StrictMath.pow > and what is allowed for in Math.pow will not cause anyone's expectations > to be challenged. However, even so I'd prefer not to surprise users. > Anyway, if Andrew Haley really wants this to be adopted then I'll accept > his override and you can leave it in Estrin form. > > 4) Repetition of code in K_IS_0/K_IS_1 branches > > In the Y_IS_NOT_HUGE block 15/17 instructions are generated in the if > and else branches for k == 0 and k == 1, implementing what is almost > exactly the same computation. The two generated sequences differ very > slightly. In the k == 1 case dp_h and dp_l need to be folded into the > computation to subtract ln2(1.5) from the result while in the k == 0 > case dp_h and dp_l are both 0.0 and can be ignored. > > The most important difference is the need to load dp_l/dp_h from the > coefficient table in one branch while the other merely moves forward the > cursor which points at the table. The other differences consist of two > extra operations in the k == 1 branch, an extra fmlavs and an extra > faddd, which fold in the dp_l and dp_h values. > > An alternative would be to use common code for the computation which > always perform the extra fmlavs and faddd. The revised algorithm > describes precisely this alternative. To make it work the k = 0 branch > needs to install 0.0 in the registers used for dp_h and dp_k (not > necessarily by loading from the table). This shortens the branches, > relocating 15 common instructions after the branch > > As far as code clarity is concerned it is easier to understand and > maintain if the common code is generated only once. As for performance, > I believe this trade off of a few more cycles against code size is also > a better choice. Shaving instructions may give a small improvement in a > benchmark, especially if the benchmark repeatedly runs with values that > exercise only one of the paths. However, in real use the extra code size > from the duplicated code is likely to push more code out of cache. Since > this is main path code that is actually quite likely to happen. > > So, I would like to see the duplication removed unless you can make a > really strong case for keeping it. If you can provide such a reason then > an explanation why the duplication is required needs to be provided in > the revised algorithm and the code and the algorithm need sot be updated > to specify both paths. > > 4) Repetition of odd/even tests in exit cases. > > The original algorithm takes the hit of computing the even/odd/fraction > status of y inline, i.e. in the main path, during special case checks. > That happens even if the result is not used later. You have chosen to do > it at the relevant exits, resulting in more repeated code. > > These cases will likely be a rare path so the issue of extra code size > is not going to be very important relative to the saved cycles. However, > the replication of inline code is a maintenance issue. > > It would be better to use a separate function to generate the common > code that computes the test values (lowest non-zero bit idx and exponent > of y) avoiding any need to read, check and fix the generator code in > different places. Please update the code accordingly. > > 5) Test code > > You need to include a test as part of this patch which checks the > outputs are correct for a few selected inputs that exercise the > underflow and Y_IS_HUGE branches. I adapted the existing Math tests to > include these extra checks: > > public static int testUnderflow() { > int failures = 0; > failures += testPowCase(1.5E-2D, 170D, 8.6201344461973E-311D); > failures += testPowCase(1.55E-2D, 171.3D, 1.00883443217485E-310D); > // failures += testPowCase(150D, 141.6D, 1.3630829399139085E308); > return failures; > } > > public static int testHugeY() { > int failures = 0; > long yl = 0x1_1000_0000L; > failures += testPowCase(1.0000000001, (double)yl, > 1.5782873649891997D); > failures += testPowCase(1.0000000001, (double)yl + 0.3, > 1.5782873650365483D); > return failures; > > You don't have to add this to the existing math test suite. A simple > standalone test which checks that the StrictMath and Math outputs agree > on these inputs is all that is needed. > > > Rework > ------ > > 1) Please check that the revised algorithm I have provided accurately > reflects the computations performed by your code. That will require > changing the code to deal with the error cases 1, 2, 4 and 5 above. If > you stick with the Estrin form in case 3 then ensure the algorithm is > correct. If you stick with Horner form then update the algorithm so it > is consistent. > > The algorithm currently details all mappings of variable to registers. > That is provided as a heuristic which i) allowed me to track usages when > writing up the algorithm and ii) will allow you to analyze the current > register mappings and rationalize them. Once you have a more coherent > strategy for allocating variables to registers details of the mapping > can and should be removed. > > As mentioned, the algorithm uses a suffix notation to distinguish > different values where there is some scope for ambiguity. The suffices > are used as follows > > 1) '_d' double values (mapped to d registers) > > 2) '_hd' and '_ld' hi/lo double pairs used to retain accuracy (mapped > to independent d registers) > > 3) '_d2' double vectors (mapped to 2d v registers) > > 4) '_r' long values that represent the long version of a double value > (mapped to general x registers) > > 5) '_h' int values that represent the high word of a double value > (mapped to general w registers) > > In many unambiguous cases a suffix is omitted e.g. x, y, k, n. > > 2) Sort out inconsistent mappings and unnecessary remappings > > One of the problems I faced in writing up the algorithm is that some of > your register use appears to be inconsistent -- the same 'logical' > variable is mapped to different registers at different points in the code. > > In some cases, this reflects different use of the same name for > different quantities calculated at different stages in the algorithm > (for example, z is used to name both log2(x) and then reused later for > the fractional part of log2(x)). Most of those reuses are actually > catered for by declaring the var in one block and then redeclaring it in > a different sibling block. If this block structure is replicated in the > code then it will enable z to be mapped differently for each different > scope. However, that's not the preferred outcome. It would make the > code easier to follow if every variable named in the algorithm was > always mapped to the same register unless there was a clear need to > relocate it. > > There are also cases where a remapping is performed (without any > discernible reason) within the same scope or within nested scopes! For > example, after the sign of x_r has been noted (and, possibly, it's sign > bit removed) the resulting absolute value of x_r is moved from r0 to r1 > (using an explicit mov). There doesn't seem to be any need to do this. > Likewise, in the COMPUTE_POW_PROCEED block the value for z stored in v0 > is reassigned to v18 in the same block! > > I have flagged these remappings with a !!! comment and avoided the > ambiguity that arises by adding a ' to the remapped value (x_r', z') and > using it thereafter. This ensures that uses of the different versions of > the value located in different registers can be distinguished. > > An example of remapping in nested scope is provided by p_hd and p_ld. At > the outermost scope these values are mapped to v5 and b6. However, in > the K_IS_SET block they are stored in v17 and v16 (values for v and u, > local to the same block, are placed in v5 and v6 so there is no reason > why the outer scope mapping could not have been retained). > > I'd like to see a much more obvious and obviously consistent plan > adopted for mappings before the code is committed. > > 3) Insert my original and revised algorithms into your code in place of > the current ones. > > 4) Change the code to introduce local blocks as per the revised algorithm > > This should mostly be a simple matter of introducing braces into the > code at strategic locations (although please re-indent). > > 5) Change the code to use symbolic names for register arguments and > declare those names as Register or FloatRegister in the appropriate > local scope > > The main point of employing consistent, logical names for values defined > in the algorithm is to allow registers employed in the code to be > identified using meaningful names rather than using r0, r1, v0, v1, > tmp1, tmp2 etc. > > So, for example at the top level of the routine you need to declare > register mappings for the function global variables and then use them in > all the generated instructions e.g. the code should look like > > // double x // input arg > // double y // input arg > FloatRegister x = v0; > FloatRegister y = v1; > // long y_r // y as long bits > Register y_r = rscratch2 > // long x_r // x as long bits > Register x_r = r0 > // double one_d // 1.0d > FloatRegister one_d = v2 > > . . . > > // y_r = DOUBLE_TO_LONG(y) > fmovd(y_r, y); > // x_r = DOUBLE_TO_LONG(x) > fmovd(x_r, x) > > . . . > > Similarly, in nested blocks you need to introduce block local names for > registers and then use them in the code. For example in the > SUBNORMAL_HANDLED block > > bind(SUBNORMAL_HANDLED); > // block introduced to scope vars/labels in this region > { > Label K_IS_SET; > // int ix_h // |x| with exponent rescaled so 1 =< ix < > Register ix_h = r2; > // int k // range 0 or 1 for poly expansion > Register k = r7 > // block introduced to scope vars/labels in this subregion > { > // int x_h // high word of x > Register x_h = r2 > //int mant_x_h // mantissa bits of high word of > Register mant_x_h = r10 > > . . . > > // x_h = (x_r' >> 32) > lsr(x_h, x_r, 32); > // mant_x_h = (x_r >> 32) & 0x000FFFFF > ubfx(mant_x_h, x_r, 32, 20); // i.e. top 20 fractions bits of x > > . . . > > } > bind(K_IS_SET); > > . . . > > You should be able to hang the code directly off the algorithm as shown > above, making it clear that it matches the revised algorithm and > allowing meaningful comparison with the original. > > If you have changed the code in your latest revisions then please update > the algorithm accordingly to ensure they continue to correspond with > each other. From aph at redhat.com Fri Oct 26 13:16:53 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Oct 2018 14:16:53 +0100 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> <0abe597a-6fcc-a05c-4c5d-fb42d9ee0c1f@redhat.com> Message-ID: <158d7e0a-eb64-201a-4def-54497dfae6c6@redhat.com> On 10/26/2018 11:36 AM, Pengfei Li (Arm Technology China) wrote: > I got a reason why consecutive fmins are slower. The fmin sequence generated by the nested min() calls has RaW data dependencies. One fmin writes an fp register and the next fmin reads the same one. It leads the instruction pipeline to stall frequently. Wouldn't that also be true for a non-intrinsic fmin too? Each fp register output would be the input for a following comparison and conditional branch. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Oct 29 09:00:39 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 29 Oct 2018 09:00:39 +0000 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <978ebf83-1c79-6310-c2ae-abc283552ce6@bell-sw.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> <1b770596-8da2-74be-bad2-832bf4a6622a@redhat.com> <978ebf83-1c79-6310-c2ae-abc283552ce6@bell-sw.com> Message-ID: <99bf9bdc-b758-6516-dee5-8914739ec925@redhat.com> Hello Dmitrij, On 26/10/18 13:21, Dmitrij Pochepko wrote: > I prepared new patch with all your comments addressed. Excellent. Thank you very much for putting in all the required work. > Changes: > > - fixed huge y case > > - updated scalbn block to use approach you suggested > > - updated optimized algorithm pseudo code to reflect all changes, also > fixed few minor pseudo code issues > > - rearranged assembly code: > > -- renamed registers variables to have names correlating to C-code where > applicable > > -- introduced local blocks with local labels and register mappings where > applicable > > -- removed unnecessary register remappings > > -- moved odd/even check code generation to separate function > > -- removed K_IS_0 and K_IS_1 branches code repetition > > > - added simple jtreg test Ok. I'll try to work through this as quick as possible but it may take a day or two. > I found that one of tests I was using ( > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/lang/Math/PowTests.java) > actually skip non-corner-case testing. Still, this test has very good > set of input values, which can be re-used. I created enhancement for > this test to actually test non-corner-case values ( > https://bugs.openjdk.java.net/browse/JDK-8211002 ). I modified this test > locally to have everything testing and it passed. I have already talked to Joe Darcy about PowTests.java and he explained where this test came from and why it only covers the current set of inputs. I am sure he will be happy to have it extended to cover extra corner cases. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Pengfei.Li at arm.com Mon Oct 29 09:03:10 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 29 Oct 2018 09:03:10 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <158d7e0a-eb64-201a-4def-54497dfae6c6@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> <0abe597a-6fcc-a05c-4c5d-fb42d9ee0c1f@redhat.com> <158d7e0a-eb64-201a-4def-54497dfae6c6@redhat.com> Message-ID: Hi Andrew, > > I got a reason why consecutive fmins are slower. The fmin sequence > generated by the nested min() calls has RaW data dependencies. One fmin > writes an fp register and the next fmin reads the same one. It leads the > instruction pipeline to stall frequently. > > Wouldn't that also be true for a non-intrinsic fmin too? Each fp register > output would be the input for a following comparison and conditional > branch. In non-intrinsic generated code (see below pasted), fmovs are never executed since branches are biased to TAKEN. 0x0000ffff94d08e14: fmov d28, d19 0x0000ffff94d08e18: fcmp s28, s20 0x0000ffff94d08e1c: b.lt 0x0000ffff94d08e24 0x0000ffff94d08e20: fmov d28, d20 0x0000ffff94d08e24: fcmp s28, s17 0x0000ffff94d08e28: b.lt 0x0000ffff94d08e30 0x0000ffff94d08e2c: fmov d28, d17 0x0000ffff94d08e30: fcmp s28, s18 0x0000ffff94d08e34: b.lt 0x0000ffff94d08e3c The code sequence actually executed is: fcmp, b.lt, fcmp, b.lt, fcmp, b.lt, ... -- Thanks, Pengfei From bob.vandette at oracle.com Tue Oct 30 14:56:36 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 30 Oct 2018 10:56:36 -0400 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> <5BA38920.8020203@cjnash.com> Message-ID: <43E51870-3583-42A1-B1A3-CFD86CF975A0@oracle.com> This JEP is now targeted to JDK 12. I?ve merged up to the latest sources and will be integrating these changes in the next day or two. Here?s the latest webrev post merge in the event anyone spots any last minute issues. http://cr.openjdk.java.net/~bobv/8209093/webrev.02 Bob,. From ci_notify at linaro.org Wed Oct 31 13:59:59 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 31 Oct 2018 13:59:59 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <625786513.56.1540994399970.JavaMail.jenkins@eb8f9c77b024> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 10 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/302/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.71x Relative performance: Server critical-jOPS (nc): 8.43x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 10 days. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From bob.vandette at oracle.com Wed Oct 31 19:06:45 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 31 Oct 2018 15:06:45 -0400 Subject: [aarch64-port-dev ] RFR: 8213204 - ReservedStackTest and ReservedStackTestCompiler tests fail on windows Message-ID: Please review this test fix that solve a problem with a regression that was introduced with the changes done to remove one of the AARCH64 ports (https://bugs.openjdk.java.net/browse/JDK-8209093). BUG: https://bugs.openjdk.java.net/browse/JDK-8213204 WEBREV: http://cr.openjdk.java.net/~bobv/8213204/webrev Here is the effective change that I should have done to this test when removing the Hybrid arm64 port. diff --git a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java --- a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java +++ b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java @@ -233,19 +233,16 @@ } private static boolean isAlwaysSupportedPlatform() { - // Note: To date Aarch64 is the only platform that we don't statically - // know if it supports the reserved stack area. This is because the - // open Aarch64 port supports it and the Oracle arm64 port does not. return Platform.isAix() || (Platform.isLinux() && (Platform.isPPC() || Platform.isS390x() || Platform.isX64() || - Platform.isX86())) || + Platform.isX86() || Platform.isAArch64())) || Platform.isOSX() || Platform.isSolaris(); } private static boolean isNeverSupportedPlatform() { - return !isAlwaysSupportedPlatform() && !Platform.isAArch64(); + return !isAlwaysSupportedPlatform(); } private static boolean isSupportedPlatform; Bob. From daniel.daugherty at oracle.com Wed Oct 31 20:22:52 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 31 Oct 2018 16:22:52 -0400 Subject: [aarch64-port-dev ] RFR: 8213204 - ReservedStackTest and ReservedStackTestCompiler tests fail on windows In-Reply-To: <663312D0-E581-4C76-8578-4B6D1E88CCD3@oracle.com> References: <663312D0-E581-4C76-8578-4B6D1E88CCD3@oracle.com> Message-ID: Thumbs up! Dan On 10/31/18 3:12 PM, Frederic Parain wrote: > Looks good to me. > Thank you for fixing this. > > Fred > > >> On Oct 31, 2018, at 15:06, Bob Vandette wrote: >> >> Please review this test fix that solve a problem with a regression that was introduced with the >> changes done to remove one of the AARCH64 ports (https://bugs.openjdk.java.net/browse/JDK-8209093). >> >> BUG: >> https://bugs.openjdk.java.net/browse/JDK-8213204 >> >> WEBREV: >> http://cr.openjdk.java.net/~bobv/8213204/webrev >> >> >> Here is the effective change that I should have done to this test when removing the Hybrid arm64 port. >> >> >> diff --git a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java >> --- a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java >> +++ b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java >> @@ -233,19 +233,16 @@ >> } >> >> private static boolean isAlwaysSupportedPlatform() { >> - // Note: To date Aarch64 is the only platform that we don't statically >> - // know if it supports the reserved stack area. This is because the >> - // open Aarch64 port supports it and the Oracle arm64 port does not. >> return Platform.isAix() || >> (Platform.isLinux() && >> (Platform.isPPC() || Platform.isS390x() || Platform.isX64() || >> - Platform.isX86())) || >> + Platform.isX86() || Platform.isAArch64())) || >> Platform.isOSX() || >> Platform.isSolaris(); >> } >> >> private static boolean isNeverSupportedPlatform() { >> - return !isAlwaysSupportedPlatform() && !Platform.isAArch64(); >> + return !isAlwaysSupportedPlatform(); >> } >> >> private static boolean isSupportedPlatform; >> >> Bob. >> From frederic.parain at oracle.com Wed Oct 31 19:12:27 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 31 Oct 2018 15:12:27 -0400 Subject: [aarch64-port-dev ] RFR: 8213204 - ReservedStackTest and ReservedStackTestCompiler tests fail on windows In-Reply-To: References: Message-ID: <663312D0-E581-4C76-8578-4B6D1E88CCD3@oracle.com> Looks good to me. Thank you for fixing this. Fred > On Oct 31, 2018, at 15:06, Bob Vandette wrote: > > Please review this test fix that solve a problem with a regression that was introduced with the > changes done to remove one of the AARCH64 ports (https://bugs.openjdk.java.net/browse/JDK-8209093). > > BUG: > https://bugs.openjdk.java.net/browse/JDK-8213204 > > WEBREV: > http://cr.openjdk.java.net/~bobv/8213204/webrev > > > Here is the effective change that I should have done to this test when removing the Hybrid arm64 port. > > > diff --git a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java > --- a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java > +++ b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java > @@ -233,19 +233,16 @@ > } > > private static boolean isAlwaysSupportedPlatform() { > - // Note: To date Aarch64 is the only platform that we don't statically > - // know if it supports the reserved stack area. This is because the > - // open Aarch64 port supports it and the Oracle arm64 port does not. > return Platform.isAix() || > (Platform.isLinux() && > (Platform.isPPC() || Platform.isS390x() || Platform.isX64() || > - Platform.isX86())) || > + Platform.isX86() || Platform.isAArch64())) || > Platform.isOSX() || > Platform.isSolaris(); > } > > private static boolean isNeverSupportedPlatform() { > - return !isAlwaysSupportedPlatform() && !Platform.isAArch64(); > + return !isAlwaysSupportedPlatform(); > } > > private static boolean isSupportedPlatform; > > Bob. >