From dmitrij.pochepko at bell-sw.com Fri Jun 1 13:21:36 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 1 Jun 2018 16:21:36 +0300 Subject: [aarch64-port-dev ] RFR: 8189105: AARCH64: create intrinsic for sin and cos Message-ID: Hi, please review patch for JDK-8189105: AARCH64: create intrinsic for sin and cos This patch adds intrinsics for Math::sin(double) and Math::cos(double). It implements algorithm for sin and cos from sharedRuntimeTrig.cpp, which is a variation of classical libm algorithm implementation. Main difference is in heavy SIMD instructions usage, which shortens execution. Also few minor optimizations like pipelining instructions, range-check-based optimizations, optimized constants loading were applied. Performance: I created simple benchmark for sin and cos: http://cr.openjdk.java.net/~dpochepk/8189105/MathBench.java It checks few values, because of different algorithm branches are taken. Results summary: ThunderX2: up to x1.7 improvement ThunderX: up to x1.4 Cortex A53: up to x1.4 Cortex A73: up to 1.65 Detailed results can be seen here: http://cr.openjdk.java.net/~dpochepk/8189105/math-sin.xls Testing: I launched jdk jtreg test for sin/cos functions: (./test/jdk/java/lang/Math/SinCosCornerCasesTests.java) in both Xmixed and Xcomp modes Also I launched respective JCK tests (api/java_lang/Math/sin* and api/java_lang/Math/cos*) in both Xmixed and Xcomp modes All passed, no failures found. webrev: http://cr.openjdk.java.net/~dpochepk/8189105/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8189105 NOTE: This patch depends on my another patch for Math::log (JDK-8196402), which adds new instructions into assembler_aarch64.hpp: frecpe, faddpd, fmlavs, fmlsvs, fmulxvs Thanks, Dmitrij From aph at redhat.com Fri Jun 1 13:45:08 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Jun 2018 14:45:08 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> Message-ID: <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> On 05/21/2018 09:35 PM, Dmitrij Pochepko wrote: > > > On 21.05.2018 17:45, Andrew Haley wrote: >> On 05/21/2018 02:55 PM, Dmitrij Pochepko wrote: >>> webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.01/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8196402 >> This looks basically reasonable, given that it seems to be a somewhat >> straightforward adaptation of the x86 code. >> However, a couple of >> things: >> >> The assembler changes should be parameterized as much as possible. >> For example, fmlavvd, fmulxvsd, and fmulxssd are cases of the "AdvSIMD >> vector x indexed element" class. fmlavvd is a case of "AdvSIMD three >> same", some of which already exist. If you can extend an existing >> group of instructions, please do. > I couldn't merge new instructions with existing (encoding looks quite > different), but I've managed to parametrize several new instructions > into more compact code. Looks much better. >> >> Given that this is an adaptation of the Intel code, please do two >> things: >> >> Put it in the same place that corresponds to its position in the x86 >> files. >> >> Keep Intel's copyright. > done. And add your own. With the current date:-) >> Thanks. >> > Please take a look at 2nd webrev: > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.02/ > I've tested modified patch with jdk jtreg tests. This comment looks wrong: 41 // Get B~1/mx based on the output of rcpss instruction (B0) Otherwise OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Jun 1 15:11:11 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 1 Jun 2018 18:11:11 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> Message-ID: <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> On 01.06.2018 16:45, Andrew Haley wrote: > On 05/21/2018 09:35 PM, Dmitrij Pochepko wrote: >> >> On 21.05.2018 17:45, Andrew Haley wrote: >>> On 05/21/2018 02:55 PM, Dmitrij Pochepko wrote: >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.01/ >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8196402 >>> This looks basically reasonable, given that it seems to be a somewhat >>> straightforward adaptation of the x86 code. >>> However, a couple of >>> things: >>> >>> The assembler changes should be parameterized as much as possible. >>> For example, fmlavvd, fmulxvsd, and fmulxssd are cases of the "AdvSIMD >>> vector x indexed element" class. fmlavvd is a case of "AdvSIMD three >>> same", some of which already exist. If you can extend an existing >>> group of instructions, please do. >> I couldn't merge new instructions with existing (encoding looks quite >> different), but I've managed to parametrize several new instructions >> into more compact code. > Looks much better. > >>> Given that this is an adaptation of the Intel code, please do two >>> things: >>> >>> Put it in the same place that corresponds to its position in the x86 >>> files. >>> >>> Keep Intel's copyright. >> done. > And add your own. With the current date:-) Ahh, forgot it. Thank you. Added. > >>> Thanks. >>> >> Please take a look at 2nd webrev: >> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.02/ >> I've tested modified patch with jdk jtreg tests. > This comment looks wrong: > > 41 // Get B~1/mx based on the output of rcpss instruction (B0) > > Otherwise OK. Yes. You're right. For AARCH64 it's frecpe. Fixed comment. > Updated webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.03/ Thanks, Dmitrij From dms at samersoff.net Sun Jun 3 14:03:48 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 3 Jun 2018 17:03:48 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> Message-ID: Dmitrij, This version of the fix looks good to me. -Dmitry On 06/01/2018 06:11 PM, Dmitrij Pochepko wrote: > > > On 01.06.2018 16:45, Andrew Haley wrote: >> On 05/21/2018 09:35 PM, Dmitrij Pochepko wrote: >>> >>> On 21.05.2018 17:45, Andrew Haley wrote: >>>> On 05/21/2018 02:55 PM, Dmitrij Pochepko wrote: >>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.01/ >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8196402 >>>> This looks basically reasonable, given that it seems to be a somewhat >>>> straightforward adaptation of the x86 code. >>>> ??? However, a couple of >>>> things: >>>> >>>> The assembler changes should be parameterized as much as possible. >>>> For example, fmlavvd, fmulxvsd, and fmulxssd are cases of the "AdvSIMD >>>> vector x indexed element" class.? fmlavvd is a case of "AdvSIMD three >>>> same", some of which already exist.? If you can extend an existing >>>> group of instructions, please do. >>> I couldn't merge new instructions with existing (encoding looks quite >>> different), but I've managed to parametrize several new instructions >>> into more compact code. >> Looks much better. >> >>>> Given that this is an adaptation of the Intel code, please do two >>>> things: >>>> >>>> Put it in the same place that corresponds to its position in the x86 >>>> files. >>>> >>>> Keep Intel's copyright. >>> done. >> And add your own.? With the current date:-) > Ahh, forgot it. Thank you. Added. >> >>>> Thanks. >>>> >>> Please take a look at 2nd webrev: >>> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.02/ >>> I've tested modified patch with jdk jtreg tests. >> This comment looks wrong: >> >> ?? 41 //??? Get B~1/mx based on the output of rcpss instruction (B0) >> >> Otherwise OK. > Yes. You're right. For AARCH64 it's frecpe. Fixed comment. >> > Updated webrev: > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.03/ > > Thanks, > Dmitrij -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dms at samersoff.net Sun Jun 3 20:18:30 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 3 Jun 2018 23:18:30 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <3421e284-fda3-ff82-29cd-70e4c4e0c8c0@oracle.com> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3421e284-fda3-ff82-29cd-70e4c4e0c8c0@oracle.com> Message-ID: <846e7d46-2fd7-cc95-d480-1fd3a28d577b@samersoff.net> Dan, I have an impression that _unextended_sp doesn't contain "unextended" value at the time we constructing frame() object on both aarch64 and x86. On x86 _unextended_sp always equals to _sp at this point, on aarch64 _unextended_sp is less or equal to _sp. if I add assert((_unextended_sp >= _sp), "DMS: unextended_sp_safe"); inside frame::frame(intptr_t* sp, intptr_t* unextended_sp, intptr_t* fp, address pc) on aarhc64 java crashes immediately (java -version). 1. #22 0x0000ffff905d7b9c in report_vm_error ( file=file at entry=0xffff91361260 "/root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp", line=line at entry=81, error_msg=error_msg at entry=0xffff91371240 "assert((_unextended_sp >= _sp)) failed", detail_fmt=detail_fmt at entry=0xffff91371228 "DMS: unextended_sp_safe") at /root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/share/utilities/debug.cpp:231 #23 0x0000ffff906e2230 in frame::frame ( pc=0xffff79081400 "\264\003_\370\277\003\037\370\266\203[\370\270\003\\\370\272\203\\\370\254\203^\370\201\r@\371\241\003^\370\201\004", fp=0xffff8fc86f70, unextended_sp=0xffff8fc86ee0, sp=, this=0xffff8fc866d0) at /root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp:81 #24 frame::sender_for_interpreter_frame (map=0xffff8fc86840, this=0xffff8fc86808) at /root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:441 #25 frame::sender (this=this at entry=0xffff8fc86808, map=map at entry=0xffff8fc86840) at /root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:493 #26 0x0000ffff90ac1f44 in vframeStreamCommon::next (this=0xffff8fc86800) at /root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/share/runtime/vframe.inline.hpp:47 #27 JVM_GetStackAccessControlContext (env=0x0, cls=) at /root/dsamersoff/esc/JDK-8203481/jdk/src/hotspot/share/prims/jvm.cpp:1357 #28 0x0000ffff79088b0c in ?? () #29 0x000000008b506a48 in ?? () (gdb) p _unextended_sp $1 = (intptr_t *) 0xffff8fc86ee0 (gdb) p _sp $2 = (intptr_t *) 0xffff8fc86f10 -Dmitry On 05/21/2018 05:28 PM, Daniel D. Daugherty wrote: > Hi Dmitry, > > I think something else must be going wrong here. The unextended SP > is typically documented like this: > > ? // This is the sp before any possible extension (adapter/locals). > ? intptr_t* unextended_sp = interpreter_frame_sender_sp(); > > and like this: > > ? // stack frames shouldn't be much larger than max_stack elements > ? // this test requires the use of unextended_sp which is the sp as seen by > ? // the current frame, and not sp which is the "raw" pc which could point > ? // further because of local variables of the callee method inserted after > ? // method arguments > ? if (fp() - unextended_sp() > 1024 + > m->max_stack()*Interpreter::stackElementSize) { > ??? return false; > ? } > > So I think this existing comment and assertion are correct: > > ??? L72: ? // unextended sp must be within the stack and above or equal sp > ??? L73: ? bool unextended_sp_safe = (unextended_sp < > thread->stack_base()) && > ??? L74: ??????????????????????????? (unextended_sp >= sp); > > Also, your proposed fix only changed this for two platforms. The same > logic exists on 'arm' and 'sparc' also. > > Dan > > > On 5/21/18 9:44 AM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> Please review small fix >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >> >> CR: >> >> https://bugs.openjdk.java.net/browse/JDK-8203481 >> >> Testing: >> >> jfr tests that depends to safe_for_sender functionality >> >> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >> >> fails on AARCH64. >> >> These tests passed after the fix. >> >> > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dmitrij.pochepko at bell-sw.com Mon Jun 4 12:43:13 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 4 Jun 2018 15:43:13 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> Message-ID: <4d2bab6f-5b11-d1f3-68a8-5f81b501e7a4@bell-sw.com> Thank you for review! On 03.06.2018 17:03, Dmitry Samersoff wrote: > Dmitrij, > > This version of the fix looks good to me. > > -Dmitry > > > On 06/01/2018 06:11 PM, Dmitrij Pochepko wrote: >> >> On 01.06.2018 16:45, Andrew Haley wrote: >>> On 05/21/2018 09:35 PM, Dmitrij Pochepko wrote: >>>> On 21.05.2018 17:45, Andrew Haley wrote: >>>>> On 05/21/2018 02:55 PM, Dmitrij Pochepko wrote: >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.01/ >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8196402 >>>>> This looks basically reasonable, given that it seems to be a somewhat >>>>> straightforward adaptation of the x86 code. >>>>> ??? However, a couple of >>>>> things: >>>>> >>>>> The assembler changes should be parameterized as much as possible. >>>>> For example, fmlavvd, fmulxvsd, and fmulxssd are cases of the "AdvSIMD >>>>> vector x indexed element" class.? fmlavvd is a case of "AdvSIMD three >>>>> same", some of which already exist.? If you can extend an existing >>>>> group of instructions, please do. >>>> I couldn't merge new instructions with existing (encoding looks quite >>>> different), but I've managed to parametrize several new instructions >>>> into more compact code. >>> Looks much better. >>> >>>>> Given that this is an adaptation of the Intel code, please do two >>>>> things: >>>>> >>>>> Put it in the same place that corresponds to its position in the x86 >>>>> files. >>>>> >>>>> Keep Intel's copyright. >>>> done. >>> And add your own.? With the current date:-) >> Ahh, forgot it. Thank you. Added. >>>>> Thanks. >>>>> >>>> Please take a look at 2nd webrev: >>>> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.02/ >>>> I've tested modified patch with jdk jtreg tests. >>> This comment looks wrong: >>> >>> ?? 41 //??? Get B~1/mx based on the output of rcpss instruction (B0) >>> >>> Otherwise OK. >> Yes. You're right. For AARCH64 it's frecpe. Fixed comment. >> Updated webrev: >> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.03/ >> >> Thanks, >> Dmitrij > From aph at redhat.com Mon Jun 4 12:53:11 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 13:53:11 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> Message-ID: On 06/03/2018 03:03 PM, Dmitry Samersoff wrote: > This version of the fix looks good to me. Note: the same applies to log as cost and sin. Please make sure that the intrinsic is used for interp, C1, and C2. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Mon Jun 4 13:09:13 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 4 Jun 2018 16:09:13 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> Message-ID: On 04.06.2018 15:53, Andrew Haley wrote: > On 06/03/2018 03:03 PM, Dmitry Samersoff wrote: >> This version of the fix looks good to me. > Note: the same applies to log as cost and sin. Please make sure that > the intrinsic is used for interp, C1, and C2. > Yes. Sin/cos change to enable intrinsics in intrp and C1 do it for all math intrinsics. I'm currently testing it From aph at redhat.com Mon Jun 4 14:30:10 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 15:30:10 +0100 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <95e9c57c-d602-0f7f-98e9-a3efbc31f4be@samersoff.net> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3421e284-fda3-ff82-29cd-70e4c4e0c8c0@oracle.com> <95e9c57c-d602-0f7f-98e9-a3efbc31f4be@samersoff.net> Message-ID: <96980146-1dcc-ff5d-97c5-cf41ad35cdc0@redhat.com> On 05/23/2018 08:16 AM, Dmitry Samersoff wrote: > > I'll re-check what is happening on AArch64 and come back. I had a look. I know what's happening. While we're interpreting, the machine SP is always <= the Java expression SP, ESP. When we enter a new intrpreted frame, the old machine SP is saved in interpreter_frame_sender_sp in the new frame and the machine SP is adjusted so that it is just below ESP. interpreter_frame_sender_sp is used to calculate the unextended_sp while we're unwinding the frame. So, A correct frame layout can look like this: 0x000003ffb61bdf40: 0x000003ffb61bdfb0 #2 method java.security.AccessController.getContext()Ljava/security/AccessControlContext; @ 0 - 1 locals 5 max stack 0x000003ffb61bdf38: 0x000003ffb61bdf20 interpreter_frame_sender_sp 0x000003ffb61bdf30: 0x000003ffb61bdef0 interpreter_frame_last_sp 0x000003ffb61bdf28: 0x000003ff88fb0bc0 interpreter_frame_method 0x000003ffb61bdf20: 0x0000000000000000 unextended_sp for #3 interpreter_frame_mdp 0x000003ffb61bdf18: 0x0000000000000000 0x000003ffb61bdf10: 0x000000070ff06a48 interpreter_frame_mirror 0x000003ffb61bdf08: 0x000003ff88fb0de8 interpreter_frame_cache 0x000003ffb61bdf00: 0x000003ffb61bdf50 interpreter_frame_locals 0x000003ffb61bdef8: 0x000003ff88fb0b90 interpreter_frame_bcp 0x000003ffb61bdef0: 0x000003ffb61bdef0 interpreter_frame_initial_sp 0x000003ffb61bdee8: 0x000000070ff06a48 0x000003ffb61bdee0: 0x0000000000000000 sp for #2 0x000003ffb61bded8: 0x000003ffa1081360 0x000003ffb61bded0: 0x000003ffb61bdf40 #1 method java.security.AccessController.getStackAccessControlContext()Ljava/security/AccessControlContext; @ 0 - 0 locals 1 max stack 0x000003ffb61bdec8: 0x000003ffb61bdeb0 interpreter_frame_sender_sp 0x000003ffb61bdec0: 0x0000000000000000 interpreter_frame_last_sp 0x000003ffb61bdeb8: 0x000003ff88fb0a30 interpreter_frame_method 0x000003ffb61bdeb0: 0x0000000000000000 unextended_sp for #2 interpreter_frame_mdp 0x000003ffb61bdea8: 0x0000000000000000 0x000003ffb61bdea0: 0x000000070ff06a48 interpreter_frame_mirror 0x000003ffb61bde98: 0x000003ff88fb0de8 interpreter_frame_cache 0x000003ffb61bde90: 0x000003ffb61bdee8 interpreter_frame_locals 0x000003ffb61bde88: 0x0000000000000000 interpreter_frame_bcp 0x000003ffb61bde80: 0x000003ffb61bde80 sp for #1 interpreter_frame_initial_sp unextended_sp for #1 Note that getStackAccessControlContext()'s saved sender SP from AccessController.getContext() is 0x000003ffb61bdeb0: this really is less than 0x000003ffb61bdee0, which was the SP before getStackAccessControlContext()'s frame was created. This is OK, and explains why the assert failed for you. Given that the unextended_sp can be greater or less than the saved SP, I think the assert can be removed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Mon Jun 4 15:50:32 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 4 Jun 2018 18:50:32 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 Message-ID: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> Hi all, please review patch for JDK-8204289: AARCH64: enable math intrinsics usage in interpreter and C1 This patch enables usage of math intrinsics for interpreter and C1 in case intrinsics are implemented. Code follows that of x86 port. Testing: I've merged this patch with implemented intrinsic and launched jtreg tests and benchmark in 2 more modes: -Xint and -XX:TieredStopAtLevel=3 Benchmark scores were improved as expected of intrinsic. All tests passed. webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8204289 Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Mon Jun 4 15:50:52 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 4 Jun 2018 18:50:52 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> Message-ID: On 04.06.2018 16:09, Dmitrij Pochepko wrote: > On 04.06.2018 15:53, Andrew Haley wrote: >> On 06/03/2018 03:03 PM, Dmitry Samersoff wrote: >>> This version of the fix looks good to me. >> Note: the same applies to log as cost and sin.? Please make sure that >> the intrinsic is used for interp, C1, and C2. >> > Yes. Sin/cos change to enable intrinsics in intrp and C1 do it for all > math intrinsics. I'm currently testing it Please take a look at updated webrev. The only change is move log stub generation call from generate_all() to generate_initial(). It will be required for interpreter to use initialized stub routine address after JDK-8204289 is pushed http://cr.openjdk.java.net/~dpochepk/8196402/webrev.04/ Thanks, Dmitrij From aph at redhat.com Mon Jun 4 16:30:59 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 17:30:59 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <774f2316-aa08-9b5b-ce7e-dde7e5e962c1@redhat.com> <75a37ce3-0a8a-5fee-4836-e5c9de479e6a@redhat.com> <07fa3cdd-4cc7-5e66-0c38-54b1b9100016@redhat.com> <7483cc64-7c86-d815-ced8-2cc8a6ab068f@redhat.com> <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> Message-ID: <86952d1c-3c73-720f-4050-f01f8823285a@redhat.com> On 05/31/2018 09:37 AM, Roman Kennke wrote: > Has anybody else gotten to review this in the meantime? Is it ok to go? I had a look. I didn't scan the Shenadoah changes, but the shared code changes mostly look innocuous. I didn't look at the tests either. These changes are not all Shenadoah-guarded. I don't know what effect they might have. We need at least to justify any changes to shared code. +++ b/src/share/vm/opto/lcm.cpp @@ -638,9 +638,12 @@ //------------------------------add_call_kills------------------------------------- // helper function that adds caller save registers to MachProjNode -static void add_call_kills(MachProjNode *proj, RegMask& regs, const char* save_policy, bool exclude_soe) { +static void add_call_kills(MachProjNode *proj, RegMask& regs, const char* save_policy, bool exclude_soe, bool exclude_fp) { // Fill in the kill mask for the call for( OptoReg::Name r = OptoReg::Name(0); r < _last_Mach_Reg; r=OptoReg::add(r,1) ) { + if (exclude_fp && (register_save_type[r] == Op_RegF || register_save_type[r] == Op_RegD)) { + continue; + } @@ -930,7 +938,7 @@ map_node_to_block(proj, block); block->insert_node(proj, phi_cnt++); - add_call_kills(proj, regs, _matcher._c_reg_save_policy, false); + add_call_kills(proj, regs, _matcher._c_reg_save_policy, false, false); } diff --git a/src/share/vm/opto/cfgnode.cpp b/src/share/vm/opto/cfgnode.cpp --- a/src/share/vm/opto/cfgnode.cpp +++ b/src/share/vm/opto/cfgnode.cpp @@ -1153,20 +1153,6 @@ if (id != NULL) return id; } - if (phase->is_IterGVN()) { - // A memory Phi could only have data inputs if that Phi was input - // to a MergeMem and MergeMemNode::Ideal() found that it's - // equivalent to the base memory Phi. If data uses are removed, - // the Phi will be removed as well. If one of the Phi inputs has - // changed in the meantime (shenandoah write barrier moved out of - // loop for instance), that input is disconnected from the memory - // graph. - Node* other_phi = has_only_data_users(); - if (other_phi != NULL) { - return other_phi; - } - } - return this; // No identity } @@ -2122,30 +2108,6 @@ _dest_bci == ((JumpProjNode&)n)._dest_bci; } -PhiNode* PhiNode::has_only_data_users() const { - if (!UseShenandoahGC || bottom_type() != Type::MEMORY || adr_type() == TypePtr::BOTTOM || outcnt() == 0) { - return NULL; - } - for (DUIterator_Fast imax, i = fast_outs(imax); i < imax; i++) { - Node* u = fast_out(i); - if (u->Opcode() != Op_ShenandoahReadBarrier) { - return NULL; - } - } - Node* r = in(0); - if (r == NULL) { - return NULL; - } - for (DUIterator_Fast imax, i = r->fast_outs(imax); i < imax; i++) { - Node* u = r->fast_out(i); - if (u != this && u->is_Phi() && u->bottom_type() == Type::MEMORY && - u->adr_type() == TypePtr::BOTTOM) { - return u->as_Phi(); - } - } - return NULL; -} - #ifndef PRODUCT void JumpProjNode::dump_spec(outputStream *st) const { ProjNode::dump_spec(st); diff --git a/src/share/vm/opto/cfgnode.hpp b/src/share/vm/opto/cfgnode.hpp --- a/src/share/vm/opto/cfgnode.hpp +++ b/src/share/vm/opto/cfgnode.hpp @@ -220,8 +220,6 @@ #else //ASSERT void verify_adr_type(bool recursive = false) const {} #endif //ASSERT - - PhiNode* has_only_data_users() const; }; //------------------------------GotoNode--------------------------------------- diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp --- a/src/share/vm/opto/compile.cpp +++ b/src/share/vm/opto/compile.cpp @@ -416,9 +416,6 @@ record_for_igvn(n->fast_out(i)); } } - if (n->is_Phi() && n->as_Phi()->has_only_data_users()) { - record_for_igvn(n); - } } // Remove useless macro and predicate opaq nodes for (int i = C->macro_count()-1; i >= 0; i--) { @@ -3149,7 +3146,6 @@ n->subsume_by(unique_in, this); } } - assert(!n->as_Phi()->has_only_data_users(), "memory Phi has no memory use"); break; #endif diff --git a/src/share/vm/opto/memnode.cpp b/src/share/vm/opto/memnode.cpp --- a/src/share/vm/opto/memnode.cpp +++ b/src/share/vm/opto/memnode.cpp @@ -4229,11 +4229,7 @@ // Warning: Do not combine this "if" with the previous "if" // A memory slice might have be be rewritten even if it is semantically // unchanged, if the base_memory value has changed. - if (can_reshape) { - set_req_X(i, new_in, phase->is_IterGVN()); - } else { - set_req(i, new_in); - } + set_req(i, new_in); progress = this; // Report progress } } diff --git a/src/share/vm/opto/node.cpp b/src/share/vm/opto/node.cpp --- a/src/share/vm/opto/node.cpp +++ b/src/share/vm/opto/node.cpp @@ -1406,8 +1406,6 @@ igvn->add_users_to_worklist( n ); } else if (n->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(n)) { igvn->add_users_to_worklist(n); - } else if (n->is_Phi() && n->as_Phi()->has_only_data_users()) { - igvn->_worklist.push(n); } } } diff --git a/src/share/vm/opto/phaseX.cpp b/src/share/vm/opto/phaseX.cpp --- a/src/share/vm/opto/phaseX.cpp +++ b/src/share/vm/opto/phaseX.cpp @@ -1300,8 +1300,6 @@ _worklist.push(in); } else if (in->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(in)) { add_users_to_worklist(in); - } else if (in->is_Phi() && in->as_Phi()->has_only_data_users()) { - _worklist.push(in); } if (ReduceFieldZeroing && dead->is_Load() && i == MemNode::Memory && in->is_Proj() && in->in(0) != NULL && in->in(0)->is_Initialize()) { @@ -1978,9 +1976,6 @@ if (old->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(old)) { igvn->add_users_to_worklist(old); } - if (old->is_Phi() && old->as_Phi()->has_only_data_users()) { - igvn->_worklist.push(old); - } } } -- 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 Jun 4 16:31:36 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2018 17:31:36 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <774f2316-aa08-9b5b-ce7e-dde7e5e962c1@redhat.com> <75a37ce3-0a8a-5fee-4836-e5c9de479e6a@redhat.com> <07fa3cdd-4cc7-5e66-0c38-54b1b9100016@redhat.com> <7483cc64-7c86-d815-ced8-2cc8a6ab068f@redhat.com> <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> Message-ID: By the way, next time if you want anyone to be able to review the code, please separate the Shenandoah changes. -- 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 Jun 4 16:57:30 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Jun 2018 18:57:30 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <86952d1c-3c73-720f-4050-f01f8823285a@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <774f2316-aa08-9b5b-ce7e-dde7e5e962c1@redhat.com> <75a37ce3-0a8a-5fee-4836-e5c9de479e6a@redhat.com> <07fa3cdd-4cc7-5e66-0c38-54b1b9100016@redhat.com> <7483cc64-7c86-d815-ced8-2cc8a6ab068f@redhat.com> <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> <86952d1c-3c73-720f-4050-f01f8823285a@redhat.com> Message-ID: <58dc0ca2-72b7-ed6d-882b-b6c2af8de218@redhat.com> On 06/04/2018 06:30 PM, Andrew Haley wrote: > On 05/31/2018 09:37 AM, Roman Kennke wrote: >> Has anybody else gotten to review this in the meantime? Is it ok to go? > > I had a look. I didn't scan the Shenadoah changes, but the shared code > changes mostly look innocuous. I didn't look at the tests either. Thank you! Rearranging replies a bit: === Real changes --- This change is safe: exclude_fp is false by default, and it is true on some Shenandoah-specific paths. We can guard the "if (exclude_fp)" with additional UseShenandoahGC, but it looks like overkill. > +++ b/src/share/vm/opto/lcm.cpp > @@ -638,9 +638,12 @@ > > //------------------------------add_call_kills------------------------------------- > // helper function that adds caller save registers to MachProjNode > -static void add_call_kills(MachProjNode *proj, RegMask& regs, const char* save_policy, bool exclude_soe) { > +static void add_call_kills(MachProjNode *proj, RegMask& regs, const char* save_policy, bool exclude_soe, bool exclude_fp) { > // Fill in the kill mask for the call > for( OptoReg::Name r = OptoReg::Name(0); r < _last_Mach_Reg; r=OptoReg::add(r,1) ) { > + if (exclude_fp && (register_save_type[r] == Op_RegF || register_save_type[r] == Op_RegD)) { > + continue; > + } > > @@ -930,7 +938,7 @@ > map_node_to_block(proj, block); > block->insert_node(proj, phi_cnt++); > > - add_call_kills(proj, regs, _matcher._c_reg_save_policy, false); > + add_call_kills(proj, regs, _matcher._c_reg_save_policy, false, false); > } === Reverts of Shenandoah-specific code --- These blocks, including all these has_only_data_users(), were added long ago for Shenandoah, and this is the revert to upstream state -- not sure why weren't they protected with UseShenandoahGC > diff --git a/src/share/vm/opto/cfgnode.cpp b/src/share/vm/opto/cfgnode.cpp > --- a/src/share/vm/opto/cfgnode.cpp > +++ b/src/share/vm/opto/cfgnode.cpp > @@ -1153,20 +1153,6 @@ > if (id != NULL) return id; > } > > - if (phase->is_IterGVN()) { > - // A memory Phi could only have data inputs if that Phi was input > - // to a MergeMem and MergeMemNode::Ideal() found that it's > - // equivalent to the base memory Phi. If data uses are removed, > - // the Phi will be removed as well. If one of the Phi inputs has > - // changed in the meantime (shenandoah write barrier moved out of > - // loop for instance), that input is disconnected from the memory > - // graph. > - Node* other_phi = has_only_data_users(); > - if (other_phi != NULL) { > - return other_phi; > - } > - } > - > return this; // No identity > } > @@ -2122,30 +2108,6 @@ > _dest_bci == ((JumpProjNode&)n)._dest_bci; > } > > -PhiNode* PhiNode::has_only_data_users() const { > - if (!UseShenandoahGC || bottom_type() != Type::MEMORY || adr_type() == TypePtr::BOTTOM || outcnt() == 0) { > - return NULL; > - } > - for (DUIterator_Fast imax, i = fast_outs(imax); i < imax; i++) { > - Node* u = fast_out(i); > - if (u->Opcode() != Op_ShenandoahReadBarrier) { > - return NULL; > - } > - } > - Node* r = in(0); > - if (r == NULL) { > - return NULL; > - } > - for (DUIterator_Fast imax, i = r->fast_outs(imax); i < imax; i++) { > - Node* u = r->fast_out(i); > - if (u != this && u->is_Phi() && u->bottom_type() == Type::MEMORY && > - u->adr_type() == TypePtr::BOTTOM) { > - return u->as_Phi(); > - } > - } > - return NULL; > -} > - > #ifndef PRODUCT > void JumpProjNode::dump_spec(outputStream *st) const { > ProjNode::dump_spec(st); > diff --git a/src/share/vm/opto/cfgnode.hpp b/src/share/vm/opto/cfgnode.hpp > --- a/src/share/vm/opto/cfgnode.hpp > +++ b/src/share/vm/opto/cfgnode.hpp > @@ -220,8 +220,6 @@ > #else //ASSERT > void verify_adr_type(bool recursive = false) const {} > #endif //ASSERT > - > - PhiNode* has_only_data_users() const; > }; > //------------------------------GotoNode--------------------------------------- > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp > +++ b/src/share/vm/opto/compile.cpp > @@ -416,9 +416,6 @@ > record_for_igvn(n->fast_out(i)); > } > } > - if (n->is_Phi() && n->as_Phi()->has_only_data_users()) { > - record_for_igvn(n); > - } > } > // Remove useless macro and predicate opaq nodes > for (int i = C->macro_count()-1; i >= 0; i--) { > @@ -3149,7 +3146,6 @@ > n->subsume_by(unique_in, this); > } > } > - assert(!n->as_Phi()->has_only_data_users(), "memory Phi has no memory use"); > break; > > #endif > diff --git a/src/share/vm/opto/node.cpp b/src/share/vm/opto/node.cpp > --- a/src/share/vm/opto/node.cpp > +++ b/src/share/vm/opto/node.cpp > @@ -1406,8 +1406,6 @@ > igvn->add_users_to_worklist( n ); > } else if (n->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(n)) { > igvn->add_users_to_worklist(n); > - } else if (n->is_Phi() && n->as_Phi()->has_only_data_users()) { > - igvn->_worklist.push(n); > } > } > } > diff --git a/src/share/vm/opto/phaseX.cpp b/src/share/vm/opto/phaseX.cpp > --- a/src/share/vm/opto/phaseX.cpp > +++ b/src/share/vm/opto/phaseX.cpp > @@ -1300,8 +1300,6 @@ > _worklist.push(in); > } else if (in->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(in)) { > add_users_to_worklist(in); > - } else if (in->is_Phi() && in->as_Phi()->has_only_data_users()) { > - _worklist.push(in); > } > if (ReduceFieldZeroing && dead->is_Load() && i == MemNode::Memory && > in->is_Proj() && in->in(0) != NULL && in->in(0)->is_Initialize()) { > @@ -1978,9 +1976,6 @@ > if (old->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(old)) { > igvn->add_users_to_worklist(old); > } > - if (old->is_Phi() && old->as_Phi()->has_only_data_users()) { > - igvn->_worklist.push(old); > - } > } > > } > --- This is the revert to upstream state, see: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/64fe89b445cd/src/share/vm/opto/memnode.cpp#l4379 > diff --git a/src/share/vm/opto/memnode.cpp b/src/share/vm/opto/memnode.cpp > --- a/src/share/vm/opto/memnode.cpp > +++ b/src/share/vm/opto/memnode.cpp > @@ -4229,11 +4229,7 @@ > // Warning: Do not combine this "if" with the previous "if" > // A memory slice might have be be rewritten even if it is semantically > // unchanged, if the base_memory value has changed. > - if (can_reshape) { > - set_req_X(i, new_in, phase->is_IterGVN()); > - } else { > - set_req(i, new_in); > - } > + set_req(i, new_in); > progress = this; // Report progress > } > } Thanks, -Aleksey From david.holmes at oracle.com Tue Jun 5 04:24:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jun 2018 14:24:30 +1000 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: References: Message-ID: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Hi Bob, Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. I think this is a good idea. Thanks, David On 5/06/2018 6:34 AM, Bob Vandette wrote: > During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit > ARM ports and contributed them to OpenJDK. These ports have been used for > years in the embedded and mobile market, making them very stable and > having the benefit of a single source base which can produce both 32 and > 64-bit binaries. The downside of this contribution is that it resulted > in two 64-bit ARM implementations being available in OpenJDK. > > I'd like to propose that we eliminate one of the 64-bit ARM ports and > encourage everyone to enhance and support the remaining 32 and 64 bit > ARM ports. This would avoid the creation of yet another port for these chip > architectures. The reduction of competing ports will allow everyone > to focus their attention on a single 64-bit port rather than diluting > our efforts. This will result in a higher quality and a more performant > implementation. > > The community at large (especially RedHat, BellSoft, Linaro and Cavium) > have done a great job of enhancing and keeping the AArch64 port up to > date with current and new Hotspot features. As a result, I propose that > we standardize the 64-bit ARM implementation on this port. > > If there are no objections, I will file a JEP to remove the 64-bit ARM > port sources that reside in jdk/open/src/hotspot/src/cpu/arm > along with any build logic. This will leave the Oracle contributed > 32-bit ARM port and the AArch64 64-bit ARM port. > > Let me know what you all think, > Bob Vandette > > From aph at redhat.com Tue Jun 5 09:27:16 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 10:27:16 +0100 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: References: Message-ID: <7aae9027-266d-46e0-0df5-bc74d6530af5@redhat.com> On 06/04/2018 09:34 PM, Bob Vandette wrote: > The community at large (especially RedHat, BellSoft, Linaro and Cavium) > have done a great job of enhancing and keeping the AArch64 port up to > date with current and new Hotspot features. As a result, I propose that > we standardize the 64-bit ARM implementation on this port. > > If there are no objections, I will file a JEP to remove the 64-bit ARM > port sources that reside in jdk/open/src/hotspot/src/cpu/arm > along with any build logic. This will leave the Oracle contributed > 32-bit ARM port and the AArch64 64-bit ARM port. Sounds good to me. Over to practical considerations: is there some code we should look at porting over to the tAArch64 port? Minimal VM, perhaps? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bob.vandette at oracle.com Tue Jun 5 14:05:29 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 5 Jun 2018 10:05:29 -0400 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: <7aae9027-266d-46e0-0df5-bc74d6530af5@redhat.com> References: <7aae9027-266d-46e0-0df5-bc74d6530af5@redhat.com> Message-ID: <27CED1F9-5C87-43BF-A00B-53A5829ADD75@oracle.com> > On Jun 5, 2018, at 5:27 AM, Andrew Haley wrote: > > On 06/04/2018 09:34 PM, Bob Vandette wrote: >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features. As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic. This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. > > Sounds good to me. Over to practical considerations: is there some > code we should look at porting over to the tAArch64 port? Minimal > VM, perhaps? I would like to keep this effort as a straight forward code deletion exercise. Adding Minimal VM support is beyond the scope of what I had in mind. We no longer regularly build the minimal VM and would prefer to leave this work to someone that has a vested interest in using and supporting it. It appears that there has been some attempt to provide ifdefs in the aarch64 source directory for this but I have no idea if this builds today or if you can even support building the client only VM. I?d be willing to work with someone during the code removal to include minimal support at that time but I think that work should be handled separately. Bob. > > -- > 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 Jun 5 15:04:44 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 16:04:44 +0100 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: <27CED1F9-5C87-43BF-A00B-53A5829ADD75@oracle.com> References: <7aae9027-266d-46e0-0df5-bc74d6530af5@redhat.com> <27CED1F9-5C87-43BF-A00B-53A5829ADD75@oracle.com> Message-ID: On 06/05/2018 03:05 PM, Bob Vandette wrote: > I would like to keep this effort as a straight forward code deletion exercise. > Adding Minimal VM support is beyond the scope of what I had in mind. > We no longer regularly build the minimal VM and would prefer to leave this work > to someone that has a vested interest in using and supporting it. Oh yes, definitely. There's no hurry, and in any case the code isn't going away. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Tue Jun 5 16:25:03 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Jun 2018 18:25:03 +0200 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> Message-ID: <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> Is anybody working on this? It blocks my testing on other unrelated patches and generally makes CI unhappy on aarch64. I am not sure it is the same or possibly related issue. We had something similar in Shenandoah land a while ago, and the fix looked like the first block here: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk/2018-06-05-v150-vs-4bb58f644e4e/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html Maybe this helps? Thanks, Roman > Hi, Andrew, > > By 'git bisect', I find this failure should be caused by this patch: > https://bugs.openjdk.java.net/browse/JDK-8202377. > > BTW, this patch also makes some jtreg case failed, like > compiler/loopopts/superword/SumRed_Int.java etc. > > On 26 May 2018 at 00:03, Andrew Haley wrote: >> This is today's jdk-jdk >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/aarch64.ad:2849 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/local/jdk-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2849), pid=18689, tid=18767 >> # assert(mbar != __null) failed: CAS not embedded in normal graph! >> # >> # JRE version: OpenJDK Runtime Environment (11.0) (slowdebug build 11-internal+0-adhoc.aph.jdk-jdk) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64) >> # Core dump will be written. Default location: /local/graal/graal/compiler/core.18689 >> # >> # An error report file with more information is saved as: >> # /local/graal/graal/compiler/hs_err_pid18689.log >> >> >> Current CompileTask: >> C2: 34583 2284 4 java.util.concurrent.ConcurrentHashMap::casTabAt (21 bytes) >> >> Stack: [0x000003ff816a0000,0x000003ff818a0000], sp=0x000003ff8189a7a0, free space=2025k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xfd1d1c] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, std::__va_list)+0x7 >> 8 >> V [libjvm.so+0x6d8ab0] report_vm_error(char const*, int, char const*, char const*, ...)+0x15c >> V [libjvm.so+0x26e54c] needs_acquiring_load_exclusive(Node const*)+0x38c >> V [libjvm.so+0x72c4a0] State::_sub_Op_CompareAndSwapN(Node const*)+0x68 >> V [libjvm.so+0x76774c] State::DFA(int, Node const*)+0x3f8 >> V [libjvm.so+0xc97f4c] Matcher::Label_Root(Node const*, State*, Node*, Node const*)+0x524 >> V [libjvm.so+0xc9753c] Matcher::match_tree(Node const*)+0x1e4 >> V [libjvm.so+0xc95c94] Matcher::xform(Node*, int)+0x168 >> V [libjvm.so+0xc92b58] Matcher::match()+0xcc0 >> V [libjvm.so+0x65d664] Compile::Code_Gen()+0x98 >> V [libjvm.so+0x656510] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x11d8 >> V [libjvm.so+0x507014] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x158 >> V [libjvm.so+0x672eb4] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x604 >> V [libjvm.so+0x671ef8] CompileBroker::compiler_thread_loop()+0x344 >> V [libjvm.so+0xf54c68] compiler_thread_entry(JavaThread*, Thread*)+0x94 >> V [libjvm.so+0xf4fb54] JavaThread::thread_main_inner()+0x194 >> V [libjvm.so+0xf4f9ac] JavaThread::run()+0x19c >> V [libjvm.so+0xd844d8] thread_native_entry(Thread*)+0x17c >> C [libpthread.so.0+0x7c10] start_thread+0xb0 >> >> >> >> -- >> 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 Jun 5 16:37:38 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jun 2018 17:37:38 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> Message-ID: <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> On 06/05/2018 05:25 PM, Roman Kennke wrote: > Is anybody working on this? It blocks my testing on other unrelated > patches and generally makes CI unhappy on aarch64. I'm waiting for Andrew Dinn to return. It's his code that was broken by the modular GC barriers change. In the meantime you can set UseBarriersForVolatile to true. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Tue Jun 5 19:46:04 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 5 Jun 2018 22:46:04 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler Message-ID: Hi all, please review small patch for 8204353 - AARCH64: optimize FPU load and stores in macroAssembler This patch optimize fpu stores and loads by using ld1/st1 instructions which handle 4 registers instead of ldp/stp (2 registers). It makes respective code up to 2 times smaller. Thus it has more changes to be optimized in CPU. Testing: I run hotspot jtreg compiler tests as sanity with patched and unpatched build. No new failures found. CR: https://bugs.openjdk.java.net/browse/JDK-8204353 webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ Thanks, Dmitrij From Derek.White at cavium.com Tue Jun 5 21:48:41 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 5 Jun 2018 21:48:41 +0000 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: Hi Dmitrij, That looks like it could help. The related question I've had on the back-burner for a while is WHY are we saving/restoring 42 registers in gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier? We don't do that around any other calls to call_VM_leaf. No other port saves the entire register set, even the arm64 port. They just save a few registers that are in use. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > Sent: Tuesday, June 05, 2018 3:46 PM > To: hotspot-compiler-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net > Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load > and stores in macroAssembler > > Hi all, > > please review small patch for 8204353 - AARCH64: optimize FPU load and > stores in macroAssembler > > This patch optimize fpu stores and loads by using ld1/st1 instructions which > handle 4 registers instead of ldp/stp (2 registers). It makes respective code > up to 2 times smaller. Thus it has more changes to be optimized in CPU. > > > Testing: I run hotspot jtreg compiler tests as sanity with patched and > unpatched build. No new failures found. > > > CR: https://bugs.openjdk.java.net/browse/JDK-8204353 > > webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ > > > Thanks, > > Dmitrij From zhongwei.yao at linaro.org Wed Jun 6 01:24:48 2018 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Wed, 6 Jun 2018 09:24:48 +0800 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> Message-ID: Hi, all, I have a patch trying to fix this issue and have sent to review at http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032806.html Please take a look. On 6 June 2018 at 00:25, Roman Kennke wrote: > Is anybody working on this? It blocks my testing on other unrelated > patches and generally makes CI unhappy on aarch64. > > I am not sure it is the same or possibly related issue. We had something > similar in Shenandoah land a while ago, and the fix looked like the > first block here: > > https://builds.shipilev.net/patch-openjdk-shenandoah-jdk/2018-06-05-v150-vs-4bb58f644e4e/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html > > Maybe this helps? > > Thanks, > Roman > > >> Hi, Andrew, >> >> By 'git bisect', I find this failure should be caused by this patch: >> https://bugs.openjdk.java.net/browse/JDK-8202377. >> >> BTW, this patch also makes some jtreg case failed, like >> compiler/loopopts/superword/SumRed_Int.java etc. >> >> On 26 May 2018 at 00:03, Andrew Haley wrote: >>> This is today's jdk-jdk >>> >>> # To suppress the following error report, specify this argument >>> # after -XX: or in .hotspotrc: SuppressErrorAt=/aarch64.ad:2849 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error (/local/jdk-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2849), pid=18689, tid=18767 >>> # assert(mbar != __null) failed: CAS not embedded in normal graph! >>> # >>> # JRE version: OpenJDK Runtime Environment (11.0) (slowdebug build 11-internal+0-adhoc.aph.jdk-jdk) >>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64) >>> # Core dump will be written. Default location: /local/graal/graal/compiler/core.18689 >>> # >>> # An error report file with more information is saved as: >>> # /local/graal/graal/compiler/hs_err_pid18689.log >>> >>> >>> Current CompileTask: >>> C2: 34583 2284 4 java.util.concurrent.ConcurrentHashMap::casTabAt (21 bytes) >>> >>> Stack: [0x000003ff816a0000,0x000003ff818a0000], sp=0x000003ff8189a7a0, free space=2025k >>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> V [libjvm.so+0xfd1d1c] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, std::__va_list)+0x7 >>> 8 >>> V [libjvm.so+0x6d8ab0] report_vm_error(char const*, int, char const*, char const*, ...)+0x15c >>> V [libjvm.so+0x26e54c] needs_acquiring_load_exclusive(Node const*)+0x38c >>> V [libjvm.so+0x72c4a0] State::_sub_Op_CompareAndSwapN(Node const*)+0x68 >>> V [libjvm.so+0x76774c] State::DFA(int, Node const*)+0x3f8 >>> V [libjvm.so+0xc97f4c] Matcher::Label_Root(Node const*, State*, Node*, Node const*)+0x524 >>> V [libjvm.so+0xc9753c] Matcher::match_tree(Node const*)+0x1e4 >>> V [libjvm.so+0xc95c94] Matcher::xform(Node*, int)+0x168 >>> V [libjvm.so+0xc92b58] Matcher::match()+0xcc0 >>> V [libjvm.so+0x65d664] Compile::Code_Gen()+0x98 >>> V [libjvm.so+0x656510] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x11d8 >>> V [libjvm.so+0x507014] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x158 >>> V [libjvm.so+0x672eb4] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x604 >>> V [libjvm.so+0x671ef8] CompileBroker::compiler_thread_loop()+0x344 >>> V [libjvm.so+0xf54c68] compiler_thread_entry(JavaThread*, Thread*)+0x94 >>> V [libjvm.so+0xf4fb54] JavaThread::thread_main_inner()+0x194 >>> V [libjvm.so+0xf4f9ac] JavaThread::run()+0x19c >>> V [libjvm.so+0xd844d8] thread_native_entry(Thread*)+0x17c >>> C [libpthread.so.0+0x7c10] start_thread+0xb0 >>> >>> >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> >> > > -- Best regards, Zhongwei From aph at redhat.com Wed Jun 6 07:59:13 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 08:59:13 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: On 06/05/2018 08:46 PM, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ OK, seems reasonable. -- 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 Wed Jun 6 08:12:18 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 09:12:18 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: <5d5e6c96-239c-557d-d2f1-4be377b83935@redhat.com> On 06/05/2018 10:48 PM, White, Derek wrote: > The related question I've had on the back-burner for a while is WHY > are we saving/restoring 42 registers in > gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier? Please point me to the exact line of code you are talking about. > We don't do that around any other calls to call_VM_leaf. > > No other port saves the entire register set, even the arm64 > port. They just save a few registers that are in use. You don't know which registers are in use. -- 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 Wed Jun 6 08:19:12 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 09:19:12 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> Message-ID: On 06/06/2018 02:24 AM, Zhongwei Yao wrote: > I have a patch trying to fix this issue and have sent to review at > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032806.html > > Please take a look. I have. I think it should be fixed in aarch64.ad, -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Jun 6 08:21:26 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Jun 2018 10:21:26 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <58dc0ca2-72b7-ed6d-882b-b6c2af8de218@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <774f2316-aa08-9b5b-ce7e-dde7e5e962c1@redhat.com> <75a37ce3-0a8a-5fee-4836-e5c9de479e6a@redhat.com> <07fa3cdd-4cc7-5e66-0c38-54b1b9100016@redhat.com> <7483cc64-7c86-d815-ced8-2cc8a6ab068f@redhat.com> <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> <86952d1c-3c73-720f-4050-f01f8823285a@redhat.com> <58dc0ca2-72b7-ed6d-882b-b6c2af8de218@redhat.com> Message-ID: <5fedf058-d7b2-b98d-68d8-d547077c53bf@redhat.com> Hello Andrew, are you ok with Aleksey's explanations? Can the changes go in? Thanks, Roman > On 06/04/2018 06:30 PM, Andrew Haley wrote: >> On 05/31/2018 09:37 AM, Roman Kennke wrote: >>> Has anybody else gotten to review this in the meantime? Is it ok to go? >> >> I had a look. I didn't scan the Shenadoah changes, but the shared code >> changes mostly look innocuous. I didn't look at the tests either. > > Thank you! > > Rearranging replies a bit: > > === Real changes > > --- This change is safe: exclude_fp is false by default, and it is true on some Shenandoah-specific > paths. We can guard the "if (exclude_fp)" with additional UseShenandoahGC, but it looks like overkill. > >> +++ b/src/share/vm/opto/lcm.cpp >> @@ -638,9 +638,12 @@ >> >> //------------------------------add_call_kills------------------------------------- >> // helper function that adds caller save registers to MachProjNode >> -static void add_call_kills(MachProjNode *proj, RegMask& regs, const char* save_policy, bool exclude_soe) { >> +static void add_call_kills(MachProjNode *proj, RegMask& regs, const char* save_policy, bool exclude_soe, bool exclude_fp) { >> // Fill in the kill mask for the call >> for( OptoReg::Name r = OptoReg::Name(0); r < _last_Mach_Reg; r=OptoReg::add(r,1) ) { >> + if (exclude_fp && (register_save_type[r] == Op_RegF || register_save_type[r] == Op_RegD)) { >> + continue; >> + } >> >> @@ -930,7 +938,7 @@ >> map_node_to_block(proj, block); >> block->insert_node(proj, phi_cnt++); >> >> - add_call_kills(proj, regs, _matcher._c_reg_save_policy, false); >> + add_call_kills(proj, regs, _matcher._c_reg_save_policy, false, false); >> } > > > === Reverts of Shenandoah-specific code > > --- These blocks, including all these has_only_data_users(), were added long ago for Shenandoah, and > this is the revert to upstream state -- not sure why weren't they protected with UseShenandoahGC > >> diff --git a/src/share/vm/opto/cfgnode.cpp b/src/share/vm/opto/cfgnode.cpp >> --- a/src/share/vm/opto/cfgnode.cpp >> +++ b/src/share/vm/opto/cfgnode.cpp >> @@ -1153,20 +1153,6 @@ >> if (id != NULL) return id; >> } >> >> - if (phase->is_IterGVN()) { >> - // A memory Phi could only have data inputs if that Phi was input >> - // to a MergeMem and MergeMemNode::Ideal() found that it's >> - // equivalent to the base memory Phi. If data uses are removed, >> - // the Phi will be removed as well. If one of the Phi inputs has >> - // changed in the meantime (shenandoah write barrier moved out of >> - // loop for instance), that input is disconnected from the memory >> - // graph. >> - Node* other_phi = has_only_data_users(); >> - if (other_phi != NULL) { >> - return other_phi; >> - } >> - } >> - >> return this; // No identity >> } >> @@ -2122,30 +2108,6 @@ >> _dest_bci == ((JumpProjNode&)n)._dest_bci; >> } >> >> -PhiNode* PhiNode::has_only_data_users() const { >> - if (!UseShenandoahGC || bottom_type() != Type::MEMORY || adr_type() == TypePtr::BOTTOM || outcnt() == 0) { >> - return NULL; >> - } >> - for (DUIterator_Fast imax, i = fast_outs(imax); i < imax; i++) { >> - Node* u = fast_out(i); >> - if (u->Opcode() != Op_ShenandoahReadBarrier) { >> - return NULL; >> - } >> - } >> - Node* r = in(0); >> - if (r == NULL) { >> - return NULL; >> - } >> - for (DUIterator_Fast imax, i = r->fast_outs(imax); i < imax; i++) { >> - Node* u = r->fast_out(i); >> - if (u != this && u->is_Phi() && u->bottom_type() == Type::MEMORY && >> - u->adr_type() == TypePtr::BOTTOM) { >> - return u->as_Phi(); >> - } >> - } >> - return NULL; >> -} >> - >> #ifndef PRODUCT >> void JumpProjNode::dump_spec(outputStream *st) const { >> ProjNode::dump_spec(st); >> diff --git a/src/share/vm/opto/cfgnode.hpp b/src/share/vm/opto/cfgnode.hpp >> --- a/src/share/vm/opto/cfgnode.hpp >> +++ b/src/share/vm/opto/cfgnode.hpp >> @@ -220,8 +220,6 @@ >> #else //ASSERT >> void verify_adr_type(bool recursive = false) const {} >> #endif //ASSERT >> - >> - PhiNode* has_only_data_users() const; >> }; >> //------------------------------GotoNode--------------------------------------- >> diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp >> --- a/src/share/vm/opto/compile.cpp >> +++ b/src/share/vm/opto/compile.cpp >> @@ -416,9 +416,6 @@ >> record_for_igvn(n->fast_out(i)); >> } >> } >> - if (n->is_Phi() && n->as_Phi()->has_only_data_users()) { >> - record_for_igvn(n); >> - } >> } >> // Remove useless macro and predicate opaq nodes >> for (int i = C->macro_count()-1; i >= 0; i--) { >> @@ -3149,7 +3146,6 @@ >> n->subsume_by(unique_in, this); >> } >> } >> - assert(!n->as_Phi()->has_only_data_users(), "memory Phi has no memory use"); >> break; >> >> #endif >> diff --git a/src/share/vm/opto/node.cpp b/src/share/vm/opto/node.cpp >> --- a/src/share/vm/opto/node.cpp >> +++ b/src/share/vm/opto/node.cpp >> @@ -1406,8 +1406,6 @@ >> igvn->add_users_to_worklist( n ); >> } else if (n->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(n)) { >> igvn->add_users_to_worklist(n); >> - } else if (n->is_Phi() && n->as_Phi()->has_only_data_users()) { >> - igvn->_worklist.push(n); >> } >> } >> } >> diff --git a/src/share/vm/opto/phaseX.cpp b/src/share/vm/opto/phaseX.cpp >> --- a/src/share/vm/opto/phaseX.cpp >> +++ b/src/share/vm/opto/phaseX.cpp >> @@ -1300,8 +1300,6 @@ >> _worklist.push(in); >> } else if (in->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(in)) { >> add_users_to_worklist(in); >> - } else if (in->is_Phi() && in->as_Phi()->has_only_data_users()) { >> - _worklist.push(in); >> } >> if (ReduceFieldZeroing && dead->is_Load() && i == MemNode::Memory && >> in->is_Proj() && in->in(0) != NULL && in->in(0)->is_Initialize()) { >> @@ -1978,9 +1976,6 @@ >> if (old->Opcode() == Op_AddP && CallLeafNode::has_only_g1_wb_pre_uses(old)) { >> igvn->add_users_to_worklist(old); >> } >> - if (old->is_Phi() && old->as_Phi()->has_only_data_users()) { >> - igvn->_worklist.push(old); >> - } >> } >> >> } >> > > --- This is the revert to upstream state, see: > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/64fe89b445cd/src/share/vm/opto/memnode.cpp#l4379 > >> diff --git a/src/share/vm/opto/memnode.cpp b/src/share/vm/opto/memnode.cpp >> --- a/src/share/vm/opto/memnode.cpp >> +++ b/src/share/vm/opto/memnode.cpp >> @@ -4229,11 +4229,7 @@ >> // Warning: Do not combine this "if" with the previous "if" >> // A memory slice might have be be rewritten even if it is semantically >> // unchanged, if the base_memory value has changed. >> - if (can_reshape) { >> - set_req_X(i, new_in, phase->is_IterGVN()); >> - } else { >> - set_req(i, new_in); >> - } >> + set_req(i, new_in); >> progress = this; // Report progress >> } >> } > > > > Thanks, > -Aleksey > From aph at redhat.com Wed Jun 6 08:23:11 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 09:23:11 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: Message-ID: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> On 06/06/2018 08:59 AM, Andrew Haley wrote: > On 06/05/2018 08:46 PM, Dmitrij Pochepko wrote: >> webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ > > OK, seems reasonable. Hold on, no. I replied too quickly. 2572 void MacroAssembler::push_call_clobbered_registers() { 2573 int step = 4 * wordSize; 2574 push(RegSet::range(r0, r18) - RegSet::of(rscratch1, rscratch2), sp); 2575 sub(sp, sp, step); 2576 mov(rscratch1, -step); 2577 // Push v0-v7, v16-v31. 2578 for (int i = 31; i>= 4; i -= 4) { 2579 if (i <= v7->encoding() || i >= v16->encoding()) 2580 st1(as_FloatRegister(i-3), as_FloatRegister(i-2), as_FloatRegister(i-1), 2581 as_FloatRegister(i), T1D, Address(sp, rscratch1)); 2582 } 2583 st1(as_FloatRegister(0), as_FloatRegister(1), as_FloatRegister(2), 2584 as_FloatRegister(3), T1D, Address(sp)); 2585 } What is "step" in rscratch1 used for here? Where do we push the registers? -- 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 Wed Jun 6 09:02:01 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 10:02:01 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <5fedf058-d7b2-b98d-68d8-d547077c53bf@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <774f2316-aa08-9b5b-ce7e-dde7e5e962c1@redhat.com> <75a37ce3-0a8a-5fee-4836-e5c9de479e6a@redhat.com> <07fa3cdd-4cc7-5e66-0c38-54b1b9100016@redhat.com> <7483cc64-7c86-d815-ced8-2cc8a6ab068f@redhat.com> <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> <86952d1c-3c73-720f-4050-f01f8823285a@redhat.com> <58dc0ca2-72b7-ed6d-882b-b6c2af8de218@redhat.com> <5fedf058-d7b2-b98d-68d8-d547077c53bf@redhat.com> Message-ID: <20432e1c-80a7-d10e-5215-6c0ec5b2df94@redhat.com> On 06/06/2018 09:21 AM, Roman Kennke wrote: > are you ok with Aleksey's explanations? Can the changes go in? Yes, sure. Reversion to upstream is good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Jun 6 09:09:53 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Jun 2018 11:09:53 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <20432e1c-80a7-d10e-5215-6c0ec5b2df94@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <774f2316-aa08-9b5b-ce7e-dde7e5e962c1@redhat.com> <75a37ce3-0a8a-5fee-4836-e5c9de479e6a@redhat.com> <07fa3cdd-4cc7-5e66-0c38-54b1b9100016@redhat.com> <7483cc64-7c86-d815-ced8-2cc8a6ab068f@redhat.com> <3cd5f4e7-8cef-e1fd-2c2b-720aaa9efd40@redhat.com> <86952d1c-3c73-720f-4050-f01f8823285a@redhat.com> <58dc0ca2-72b7-ed6d-882b-b6c2af8de218@redhat.com> <5fedf058-d7b2-b98d-68d8-d547077c53bf@redhat.com> <20432e1c-80a7-d10e-5215-6c0ec5b2df94@redhat.com> Message-ID: <7c0c3275-dc1b-c289-9a6f-47fbdfd4a5ad@redhat.com> Am 06.06.2018 um 11:02 schrieb Andrew Haley: > On 06/06/2018 09:21 AM, Roman Kennke wrote: >> are you ok with Aleksey's explanations? Can the changes go in? > > Yes, sure. Reversion to upstream is good. > Thank you! I'll run a few sanity tests (again) and then push it with tag: aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 Cheers, Roman From roman at kennke.org Wed Jun 6 09:18:41 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:41 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 8baf0c62e99d Message-ID: <201806060918.w569IfpD006055@aojmv0008.oracle.com> Changeset: 324208da2fdf Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/324208da2fdf Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 8baf0c62e99d ! .hgtags From roman at kennke.org Wed Jun 6 09:18:39 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:39 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset df0657f2912d Message-ID: <201806060918.w569IedV005995@aojmv0008.oracle.com> Changeset: fb17b2f48ea9 Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/fb17b2f48ea9 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset df0657f2912d ! .hgtags From roman at kennke.org Wed Jun 6 09:18:45 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:45 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 19bb37bae005 Message-ID: <201806060918.w569Iji5006285@aojmv0008.oracle.com> Changeset: 6a4e0561f7f1 Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/6a4e0561f7f1 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 19bb37bae005 ! .hgtags From roman at kennke.org Wed Jun 6 09:18:43 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:43 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 122531a00755 Message-ID: <201806060918.w569Ihqs006204@aojmv0008.oracle.com> Changeset: e5fd3e9c4bef Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e5fd3e9c4bef Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 122531a00755 ! .hgtags From roman at kennke.org Wed Jun 6 09:18:46 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:46 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset ed5395cf2fd9 Message-ID: <201806060918.w569IkRG006341@aojmv0008.oracle.com> Changeset: f3da49ee5753 Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/f3da49ee5753 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset ed5395cf2fd9 ! .hgtags From roman at kennke.org Wed Jun 6 09:18:47 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:47 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 271fc974e271 Message-ID: <201806060918.w569Ilth006369@aojmv0008.oracle.com> Changeset: b391cf7f2548 Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/b391cf7f2548 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset 271fc974e271 ! .hgtags From roman at kennke.org Wed Jun 6 09:18:49 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:49 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset a13654681d97 Message-ID: <201806060918.w569InKa006383@aojmv0008.oracle.com> Changeset: 91a125cedb53 Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/91a125cedb53 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset a13654681d97 ! .hgtags From roman at kennke.org Wed Jun 6 09:18:47 2018 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Jun 2018 09:18:47 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 214 new changesets Message-ID: <201806060918.w569Im3Y006377@aojmv0008.oracle.com> Changeset: cd4227dd5067 Author: zgu Date: 2017-10-05 11:39 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cd4227dd5067 Changed claim count to jint ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: c6490db606ee Author: shade Date: 2017-09-22 08:31 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c6490db606ee [backport] Verify regions status ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: 9c35adbe2982 Author: shade Date: 2017-09-22 08:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9c35adbe2982 [backport] Asynchronous region recycling ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: bb523e80de9b Author: shade Date: 2017-09-22 08:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bb523e80de9b [backport] Heap region sampling should publish region states ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.hpp Changeset: ad6c373cde2e Author: shade Date: 2017-09-22 08:35 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ad6c373cde2e [backport] Store checks should run most of the time ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 52ead108ab61 Author: shade Date: 2017-09-22 09:02 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/52ead108ab61 [backport] FreeSet refactor: bitmaps, cursors, biasing ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 0de5f0bb5121 Author: shade Date: 2017-09-22 08:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0de5f0bb5121 [backport] Trim the TLAB sizes to avoid wasteful retirement under TLAB races ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! test/gc/shenandoah/options/TestExplicitGC.java Changeset: 8ef82de294af Author: shade Date: 2017-09-22 08:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8ef82de294af [backport] Adaptive collection set selection in adaptive policy ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 0c62ebf8c6c9 Author: shade Date: 2017-09-22 08:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0c62ebf8c6c9 [backport] Make heap counters update completely asynchronous ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp Changeset: 47b7ca6c84d0 Author: shade Date: 2017-09-23 16:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/47b7ca6c84d0 [backport] Adaptive heuristics accounts trashed cset twice ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: fc93d547d324 Author: shade Date: 2017-10-11 14:01 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fc93d547d324 [backport] Ensure tasks use correct number of workers ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.hpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp + test/gc/shenandoah/TestGCThreadGroups.java Changeset: 31c3d51a4e3b Author: shade Date: 2017-09-22 08:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/31c3d51a4e3b [backport] Dynamic worker refactoring ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp Changeset: 685923fa0ecb Author: zgu Date: 2017-09-25 12:54 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/685923fa0ecb [backport] Refactoring GC phase and heap allocation tracking out of policy + src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp Changeset: f12981845cc6 Author: shade Date: 2017-09-26 10:53 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f12981845cc6 [backport] Refactor worker timings into ShenandoahPhaseTimings ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimes.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimes.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp Changeset: e73026422c02 Author: roland Date: 2017-09-27 15:52 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e73026422c02 [backport] fix TCK crash with shenandoah ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 0a97802554a5 Author: roland Date: 2017-09-27 16:55 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0a97802554a5 [backport] When Shenandoah WB is moved out of loop, connect it to correct loop memory Phi (back out and revisit previous fix) ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 062843498f9c Author: shade Date: 2017-10-02 13:09 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/062843498f9c [backport] Add comments in shenandoah_store_check on direct heap field use ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 44b9b3e1516b Author: shade Date: 2017-10-02 13:16 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/44b9b3e1516b [backport] AArch64 shenandoah_store_check should read evacuation_in_progress as byte ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Changeset: 514b7fc5fe3a Author: zgu Date: 2017-10-03 17:22 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/514b7fc5fe3a [backport] Remove ShenandoahGCWorkerPerJavaThread flag ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 2d819727eee0 Author: shade Date: 2017-10-04 14:12 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2d819727eee0 [backport] Double check for UseShenandoahGC in WB expand ! src/share/vm/opto/compile.cpp Changeset: 4a4af7cf70e5 Author: shade Date: 2017-10-05 09:34 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4a4af7cf70e5 [backport] Verifier should print verification label at liveness verification ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 335a8b07bf3d Author: shade Date: 2017-10-06 09:21 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/335a8b07bf3d [backport] Mark bitmap slices commit/uncommit + Aggregated bitmap slicing ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp + test/gc/shenandoah/options/TestObjectAlignment.java Changeset: 7a3fab868d9f Author: rkennke Date: 2017-10-11 18:19 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7a3fab868d9f [backport] Fix (external) heap iteration + TestHeapDump should unlock aggressive heuristics ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPrinter.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp + test/gc/shenandoah/jvmti/TestHeapDump.java + test/gc/shenandoah/jvmti/TestHeapDump.sh + test/gc/shenandoah/jvmti/libTestHeapDump.c Changeset: 10666b6cb6f1 Author: shade Date: 2017-10-11 21:23 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/10666b6cb6f1 [backport] Pauses that do not affect heap occupancy should not report heap ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp Changeset: 2182ce879e39 Author: shade Date: 2017-10-13 11:34 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2182ce879e39 [backport] Make sure -XX:+ShenandoahVerify comes first in the tests ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java Changeset: 59f492ea08e8 Author: shade Date: 2017-10-13 11:34 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/59f492ea08e8 [backport] Add -XX:+ShenandoahVerify to more interesting tests ! test/gc/shenandoah/HumongousThreshold.java ! test/gc/shenandoah/ShenandoahJNICritical.sh Changeset: 303a6167bf69 Author: shade Date: 2017-10-16 11:13 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/303a6167bf69 [backport] Clean up dead code ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: d82053e8848d Author: shade Date: 2017-10-26 13:48 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d82053e8848d [backport] Rewrite and fix ShenandoahHeap::marked_object_iterate ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp + test/gc/shenandoah/acceptance/SieveObjects.java Changeset: 191f4f7af225 Author: roland Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/191f4f7af225 [backport] barrier moved due to null checks needs to always fix memory edges ! src/share/vm/opto/shenandoahSupport.cpp Changeset: c3a9020a9bee Author: roland Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c3a9020a9bee [backport] Incorrect constant folding with final field and -ShenandoahOptimizeFinals ! src/share/vm/opto/phaseX.cpp Changeset: a1f6646bbf64 Author: roland Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a1f6646bbf64 [backport] AESCrypt.implEncryptBlock/AESCrypt.implDecryptBlock intrinsics assume non null inputs ! src/share/vm/opto/library_call.cpp Changeset: 82e4704ca435 Author: roland Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/82e4704ca435 [backport] keep read barriers for final instance/stable field accesses ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 9252f34e984d Author: rkennke Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9252f34e984d [backport] Added diagnostic flag ShenandoahOOMDuringEvacALot ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 5108b20b288e Author: shade Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5108b20b288e [backport] Rename dynamic heuristics to static ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/SieveObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestShenandoahArgumentRanges.java Changeset: 30e256975f40 Author: shade Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/30e256975f40 [backport] Static heuristics should use non-zero allocation threshold ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 0ee24e84e1c8 Author: shade Date: 2017-10-26 16:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0ee24e84e1c8 [backport] Static heuristics should be really static and report decisions ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 42a30aac7f8d Author: roland Date: 2017-10-30 13:35 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/42a30aac7f8d missing barriers in String intrinsics with -ShenandoahOptimizeInstanceFinals -ShenandoahOptimizeStableFinals ! src/share/vm/opto/library_call.cpp Changeset: 53c8980a0b3d Author: shade Date: 2017-11-01 22:04 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/53c8980a0b3d [backport] Control loop should wait before starting another GC cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: cb51971c0e56 Author: shade Date: 2017-11-09 19:08 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cb51971c0e56 [backport] Forcefully update counters when GC cycle is running ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 1499ea93f9d5 Author: rkennke Date: 2017-11-09 19:08 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1499ea93f9d5 [backport] Add new pinned/cset region state for evac-failure-path ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: d967a951f72c Author: shade Date: 2017-11-15 12:22 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d967a951f72c [backport] Disallow pinned_cset region moves and allocations during Full GC ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: ed82ecd295bd Author: shade Date: 2017-11-15 12:22 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ed82ecd295bd [backport] Verifier crashes when reporting multiple forwardings ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: b1a49e70cc84 Author: shade Date: 2017-11-15 12:22 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b1a49e70cc84 [backport] Report all GC status flags in hs_err ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 183dbd37569c Author: shade Date: 2017-11-15 12:22 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/183dbd37569c [backport] Workaround C1 ConstantOopWriteValue bug ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp Changeset: 47cd21fa223c Author: shade Date: 2017-11-15 12:22 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/47cd21fa223c [backport] Verify fwdptr accesses during Full GC moves ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: ec4fff4298f4 Author: shade Date: 2017-11-20 21:35 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ec4fff4298f4 [backport] Passive should opt-in the barriers, not opt-out ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 345731dd3a09 Author: shade Date: 2017-11-20 21:39 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/345731dd3a09 [backport] Enable biased locking for Shenandoah by default ! src/share/vm/runtime/arguments.cpp Changeset: 44bb6eedc843 Author: shade Date: 2017-11-27 23:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/44bb6eedc843 [backport] Make sure selective barriers enabling/disabling works ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/thread.cpp + test/gc/shenandoah/TestSelectiveBarrierFlags.java Changeset: dc81812db86f Author: shade Date: 2017-12-05 11:13 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dc81812db86f [backport] Assert Shenandoah-specific safepoints instead of generic ones ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 2c1ccdf1a6cc Author: shade Date: 2017-11-30 16:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2c1ccdf1a6cc [backport] Generic verification is possible only at Shenandoah safepoints ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 734ad14151e4 Author: shade Date: 2017-11-30 10:13 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/734ad14151e4 [backport] C2 should use heapword-sized object math ! src/share/vm/opto/macro.cpp Changeset: dac50c23b0ee Author: shade Date: 2017-11-30 16:24 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dac50c23b0ee [backport] Trim/expand test heap sizes to fit small heaps ! test/gc/shenandoah/EvilSyncBug.java ! test/gc/shenandoah/HumongousThreshold.java ! test/gc/shenandoah/TestHeapAlloc.java ! test/gc/shenandoah/TestShenandoahWithLogLevel.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/ParallelRefprocSanity.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/VerifyJCStressTest.java ! test/gc/shenandoah/options/AlwaysPreTouch.java ! test/gc/shenandoah/options/TestRegionSizeArgs.java Changeset: afbd9f7a2ecc Author: shade Date: 2017-11-30 16:37 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/afbd9f7a2ecc [backport] Report illegal transitions verbosely, and remove some no-op transitions ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: b099cffc4014 Author: shade Date: 2017-11-30 16:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b099cffc4014 [backport] Cleanup and refactor Full GC code ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp Changeset: b26405877fad Author: shade Date: 2017-11-30 16:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b26405877fad [backport] Humongous regions should support explicit pinning ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 9bb9058a89a7 Author: shade Date: 2017-11-30 18:01 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9bb9058a89a7 [backport] Eagerly drop CSet state from regions during Full GC ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 2f5fda857179 Author: shade Date: 2017-12-01 11:57 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2f5fda857179 [backport] Region sampling should lock while gathering region data ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp Changeset: 7f1bff817be3 Author: shade Date: 2017-12-01 12:44 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7f1bff817be3 [backport] Full GC should compact humongous regions ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/acceptance/AllocHumongousFragment.java Changeset: 70d97cc5683b Author: shade Date: 2017-12-01 19:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/70d97cc5683b [backport] Rework shared bool/enum flags with proper types and synchronization ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp Changeset: 123748ddb6f6 Author: shade Date: 2017-12-04 11:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/123748ddb6f6 [backport] Account trashed regions from coalesced CM-with-UR ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: efc77f05551e Author: shade Date: 2017-12-04 18:41 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/efc77f05551e [backport] ShenandoahVerifyOptoBarriers should not fail with disabled barriers ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/TestSelectiveBarrierFlags.java Changeset: 004b4cccb8c9 Author: rkennke Date: 2017-12-05 12:37 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/004b4cccb8c9 [backport] Check BS type in immByteMapBase predicate ! src/cpu/aarch64/vm/aarch64.ad Changeset: 4eeaa3b6f99e Author: shade Date: 2017-12-05 16:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4eeaa3b6f99e [backport] Optimize oop/fwdptr/hr_index verification a bit ! src/share/vm/gc_implementation/shenandoah/brooksPointer.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: 360095aab551 Author: shade Date: 2017-12-05 16:59 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/360095aab551 [backport] Optimize fwdptr region handling in ShenandoahVerifyOopClosure::verify_oop ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 71a85c5dbf76 Author: shade Date: 2017-12-05 17:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/71a85c5dbf76 [backport] SieveObjects test is too hostile to verification ! test/gc/shenandoah/acceptance/SieveObjects.java Changeset: e1b1802d7d63 Author: zgu Date: 2017-12-18 12:23 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e1b1802d7d63 [backport] Fixed compilation error of libTestHeapDump.c on Windows with VS2010 ! test/gc/shenandoah/jvmti/libTestHeapDump.c Changeset: 2c7618b5e10c Author: rkennke Date: 2017-12-21 19:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2c7618b5e10c [backport] Add missing barrier in C1 NIOCheckIndex intrinsic ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 1771c0c155c4 Author: rkennke Date: 2018-01-15 18:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1771c0c155c4 [backport] Increase test timeouts ! test/gc/shenandoah/EvilSyncBug.java ! test/gc/shenandoah/jvmti/TestHeapDump.sh Changeset: 6ece4212325d Author: shade Date: 2018-01-15 18:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6ece4212325d [backport] Report fwdptr size in JNI GetObjectSize ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/whitebox.cpp Changeset: 7f6e4baa498d Author: rkennke Date: 2018-01-15 18:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7f6e4baa498d [backport] Disable verification from non-Shenandoah VMOps. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: cd7467b35106 Author: shade Date: 2018-01-15 18:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cd7467b35106 [backport] Cleanup reset_{next|complete}_mark_bitmap ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 0d36a45668a9 Author: shade Date: 2018-01-15 18:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0d36a45668a9 [backport] Verifier should check klass pointers before attempting to reach for object size ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 73c75e571ce5 Author: shade Date: 2018-01-15 18:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/73c75e571ce5 [backport] TestSelectiveBarrierFlags times out due to too aggressive compilation mode ! test/gc/shenandoah/TestSelectiveBarrierFlags.java Changeset: 4717a8184d46 Author: zgu Date: 2018-01-15 19:21 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4717a8184d46 [backport] Shenandoah SA implementation + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeapRegionSet.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp + src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 89d0a672a4ab Author: roland Date: 2018-01-17 10:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/89d0a672a4ab [backport] Allow use of fp spills around write barrier ! src/share/vm/opto/lcm.cpp Changeset: fac35a2407de Author: shade Date: 2018-01-17 10:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fac35a2407de [backport] Rehash VMOperations and cycle driver mechanics for consistency ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp Changeset: abda74027b89 Author: zgu Date: 2018-01-17 10:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/abda74027b89 [backport] Minor cleanup, uses latest Atomic API ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp Changeset: ec5c2ccc5dbf Author: shade Date: 2018-01-17 10:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ec5c2ccc5dbf [backport] Match barrier fastpath checks better ! src/cpu/x86/vm/x86_64.ad Changeset: f25f1070e43a Author: shade Date: 2018-01-17 10:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f25f1070e43a [backport] ShenandoahWriteBarrierRB flag to conditionally disable RB on WB fastpath ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: e6f8c8104554 Author: shade Date: 2018-01-22 12:04 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e6f8c8104554 Do not put down update-refs-in-progress flag concurrently ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: c460a95f8bf0 Author: rkennke Date: 2018-01-17 15:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c460a95f8bf0 Defer cleaning of system dictionary and friends to parallel cleaning phase ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: e8a3905f3ba8 Author: zgu Date: 2018-01-18 08:23 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e8a3905f3ba8 Bitmap size might not be page aligned when large page is used ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: db35a2ece677 Author: shade Date: 2018-01-24 19:14 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/db35a2ece677 VerifyJCStressTest should test all heuristics ! test/gc/shenandoah/acceptance/VerifyJCStressTest.java Changeset: 4b7d6ffb71b4 Author: shade Date: 2018-01-19 18:49 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4b7d6ffb71b4 Allocation failure injection machinery ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/SieveObjects.java Changeset: 119e9a5b24d5 Author: shade Date: 2018-02-07 12:16 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/119e9a5b24d5 Workaround VM crash with JNI Weak Refs handling ! src/share/vm/memory/referenceProcessor.cpp + test/gc/shenandoah/jni/TestJNIGlobalRefs.java + test/gc/shenandoah/jni/TestJNIGlobalRefs.sh + test/gc/shenandoah/jni/libTestJNIGlobalRefs.c Changeset: 87b1348633f9 Author: shade Date: 2018-02-19 18:45 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/87b1348633f9 [backport] LotsOfCycles test timeouts ! test/gc/shenandoah/LotsOfCycles.java Changeset: e367898607ac Author: shade Date: 2018-01-15 12:19 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e367898607ac [backport] Single thread-local GC state flag for all barriers ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/thread.inline.hpp Changeset: cb7e70cf19c4 Author: shade Date: 2018-01-16 20:23 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cb7e70cf19c4 [backport] ShConcurrentThread races with set_gc_state_bit ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: ce21830f07c7 Author: shade Date: 2018-01-15 12:32 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ce21830f07c7 [backport] GC state testers (infra) ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/shenandoahSupport.hpp + test/gc/shenandoah/compiler/TestCommonGCLoads.java Changeset: 560736646663 Author: shade Date: 2018-02-19 18:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/560736646663 [backport] Protect C2 matchers with UseShenandoahGC ! src/share/vm/opto/shenandoahSupport.cpp Changeset: dd3a93c91223 Author: shade Date: 2018-01-17 15:37 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dd3a93c91223 [backport] Refactor allocation failure and explicit GC handling ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: e5c64b1ab610 Author: shade Date: 2018-01-22 10:10 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e5c64b1ab610 [backport] Make concurrent precleaning log message optional again ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 052f9a8b2c9f Author: shade Date: 2018-01-17 16:08 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/052f9a8b2c9f [backport] Make degenerated update-refs use region-set cursor to hand over work ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 9e7a3b8fb460 Author: shade Date: 2018-01-19 11:52 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9e7a3b8fb460 [backport] Demote warning message about OOM-during-evac to informational ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp Changeset: a2de2d1d7e9f Author: shade Date: 2018-01-19 16:27 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a2de2d1d7e9f [backport] TestSelectiveBarrierFlags should accept multi-element flag selections ! test/gc/shenandoah/TestSelectiveBarrierFlags.java Changeset: 725807724443 Author: rkennke Date: 2018-01-19 18:40 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/725807724443 [backport] Implement flag to generate write-barriers without membars ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: fbc34c5d1e46 Author: shade Date: 2018-01-22 10:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fbc34c5d1e46 [backport] Log message on ref processing, class unload, update refs for mark events ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 6cd81b02b788 Author: rkennke Date: 2018-01-23 21:20 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6cd81b02b788 [backport] Add ShenandoahRootProcessor API to report threads while scanning roots ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: 21db8a3163f4 Author: rkennke Date: 2018-01-24 15:09 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/21db8a3163f4 [backport] Relax assert in SBS::is_safe() ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp Changeset: 01e4f71ef209 Author: shade Date: 2018-01-26 17:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/01e4f71ef209 [backport] Conditionalize PerfDataMemorySize on enabled heap sampling ! src/share/vm/runtime/arguments.cpp Changeset: ceb0c5513794 Author: rkennke Date: 2018-01-30 12:20 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ceb0c5513794 [backport] Make major GC phases exclusive from each other ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp Changeset: 7334a5b9d04f Author: shade Date: 2018-01-31 12:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7334a5b9d04f [backport] Single GCTimer shared by all operations ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: 8c21cbefced6 Author: rkennke Date: 2018-01-31 21:14 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8c21cbefced6 [backport] Don't treat allocation regions implicitely live during some GCs ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: bf3eff93607a Author: shade Date: 2018-02-01 12:12 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bf3eff93607a [backport] Fix Mac OS build warnings ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 0e4f44683ce9 Author: rkennke Date: 2018-02-02 14:59 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0e4f44683ce9 [backport] Record cycle start/end to avoid continuous periodic GC ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: caa7dcc9992f Author: rkennke Date: 2018-02-02 16:19 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/caa7dcc9992f [backport] Improve/more detailed timing stats for root queue work ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 41930979f592 Author: rkennke Date: 2018-02-07 12:02 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/41930979f592 [backport] Fix/improve CLD processing ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: 9b4f7a119ae2 Author: shade Date: 2018-02-07 12:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9b4f7a119ae2 [backport] Use leftmost region in GC allocations Contributed-by: Dominik Infuehr ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: b346290a0094 Author: shade Date: 2018-02-12 15:18 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b346290a0094 [backport] Cleanup and strengthen BrooksPointer verification ! src/share/vm/gc_implementation/shenandoah/brooksPointer.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: 56963c8e4d7e Author: shade Date: 2018-02-12 15:22 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/56963c8e4d7e [backport] Remove BS:is_safe in favor of logged BS::verify_safe_oop ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/oop.hpp Changeset: 9dc36af6e578 Author: shade Date: 2018-02-13 12:27 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9dc36af6e578 [backport] Rich assertion failure logging ! src/share/vm/gc_implementation/shenandoah/brooksPointer.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: ca2cbb5ccc01 Author: shade Date: 2018-02-13 13:03 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ca2cbb5ccc01 [backport] Rename *_oop_static/oop_ref to *_forwarded ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp Changeset: 50a755238dcb Author: shade Date: 2018-02-13 17:05 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/50a755238dcb [backport] Get easy on template instantiations in ShConcMark ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp Changeset: 622f260b29ea Author: shade Date: 2018-02-14 16:58 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/622f260b29ea [backport] Improve assertion/verification messages a bit ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 0aefe94448c7 Author: shade Date: 2018-02-15 17:57 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0aefe94448c7 [backport] Demote ShenandoahAllocImplicitLive to diagnostic ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: e08ca1638d42 Author: zgu Date: 2018-02-26 11:54 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e08ca1638d42 Fixed Windows build ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: c568665a3fb2 Author: roland Date: 2018-02-16 09:03 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c568665a3fb2 [backport] ShenandoahWriteBarrierNode::find_bottom_mem() fix ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 8583963f8989 Author: rkennke Date: 2018-02-16 15:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8583963f8989 [backport] Move barriers into typeArrayOop.hpp direct memory accessors ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/heapDumper.cpp Changeset: e844506cef22 Author: shade Date: 2018-02-16 18:45 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e844506cef22 [backport] Roots verification should take the special roots first ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp Changeset: 3833c888d34c Author: shade Date: 2018-02-21 18:03 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3833c888d34c [backport] Refactor allocation metadata handling ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 6b1807fc41c9 Author: shade Date: 2018-02-21 18:03 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6b1807fc41c9 [backport] Denser ShHeapRegion status line ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 0c8cf7fa6dc3 Author: shade Date: 2018-02-22 19:01 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0c8cf7fa6dc3 [backport] Record Shenandoah events in hs_err events section ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f9c82869ff01 Author: zgu Date: 2018-02-22 13:36 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f9c82869ff01 [backport] Fixed code roots scanning that might be bypassed during degenerated cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp Changeset: d96cf0f4558f Author: rkennke Date: 2018-02-22 22:37 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d96cf0f4558f [backport] Consistent liveness for humongous regions ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 835df0f6bd6c Author: shade Date: 2018-02-23 13:07 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/835df0f6bd6c [backport] RP closures should accept NULL referents ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp + test/gc/shenandoah/acceptance/RefprocSanity.java Changeset: e4a4d4ec2a9a Author: shade Date: 2018-02-26 12:09 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e4a4d4ec2a9a [backport] ReferenceProcessor is_alive setup is racy ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: f29ba8ee3d85 Author: shade Date: 2018-02-26 18:00 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f29ba8ee3d85 [backport] Speed up asserts and verification, improve fastdebug builds performance ! src/share/vm/gc_implementation/shenandoah/brooksPointer.hpp ! src/share/vm/gc_implementation/shenandoah/brooksPointer.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: ddfda04a2534 Author: shade Date: 2018-02-28 11:02 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ddfda04a2534 Missing event log for canceled GC ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: ff57d3370f76 Author: shade Date: 2018-01-22 12:52 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ff57d3370f76 [backport] Degenerated GC ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.hpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 1c99aef83715 Author: shade Date: 2018-03-04 21:53 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1c99aef83715 [backport] Arraycopy fixes (tests and infrastructure) ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp + test/gc/shenandoah/TestArrayCopyCheckCast.java + test/gc/shenandoah/TestArrayCopyStress.java Changeset: bc0f0cfed315 Author: rkennke Date: 2018-03-02 19:42 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bc0f0cfed315 [backport] Fixed pinned region handling in mark-compact ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp + test/gc/shenandoah/PinnedGarbage.java + test/gc/shenandoah/PinnedGarbage.sh + test/gc/shenandoah/libPinnedGarbage.c Changeset: 8d52288f365d Author: shade Date: 2018-03-02 19:43 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8d52288f365d [backport] Cleanup allocation tracking in heuristics ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 7ee66c1dff39 Author: shade Date: 2018-03-02 19:43 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7ee66c1dff39 [backport] Setup process references and class unloading once before the cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: d1d4129817c6 Author: shade Date: 2018-03-02 19:43 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d1d4129817c6 [backport] Print message when heuristics changes the setting ergonomically ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 0317e621f4a5 Author: shade Date: 2018-03-02 19:43 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0317e621f4a5 [backport] Refactor uncommit handling: react on explicit GCs, feature kill flag, etc ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/acceptance/HeapUncommit.java Changeset: 7123b2348cc7 Author: shade Date: 2018-03-02 22:12 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7123b2348cc7 [backport] "Compact" heuristics for dense footprint scenarios ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/SieveObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java Changeset: 575c112f7c05 Author: shade Date: 2018-03-13 11:15 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/575c112f7c05 StringInternCleanup times out ! test/gc/shenandoah/acceptance/StringInternCleanup.java Changeset: c7e5039bd665 Author: shade Date: 2018-03-05 13:31 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c7e5039bd665 [backport] Excessive assert in ShHeap::mark_next ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 3a87fe75148f Author: rkennke Date: 2018-03-05 18:14 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3a87fe75148f [backport] Eliminate write-barrier assembly stub (part 1) ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 571e1e4f32f0 Author: shade Date: 2018-03-05 17:05 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/571e1e4f32f0 [backport] Degenerated GC: rename enum, report degen reasons in stats ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 6a5084d9950f Author: shade Date: 2018-03-07 11:19 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6a5084d9950f [backport] Use os::naked_short_sleep instead of naked Thread events for sleeping ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: d3bd762755af Author: shade Date: 2018-03-07 11:19 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d3bd762755af [backport] No need for fence in control loop: flags are now ShSharedVariables ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp Changeset: e73747f9ffd9 Author: rkennke Date: 2018-03-07 22:28 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e73747f9ffd9 [backport] Implement protocol for safe OOM during evacuation handling + Use jint in oom-evac-handler to match older JDKs Atomic support better + Missing OOMScope in ShenandoahFixRootsTask ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 8057a8c9d64b Author: zgu Date: 2018-03-08 10:15 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8057a8c9d64b [backport] Minor cleanups ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp Changeset: 49de3fe72295 Author: shade Date: 2018-03-08 16:19 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/49de3fe72295 [backport] Make control loop more responsive under allocation pressure ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: dbb283b18afc Author: shade Date: 2018-03-08 16:19 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dbb283b18afc [backport] Split live data management for allocations and GCs ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: f43f1c5a9909 Author: zgu Date: 2018-03-14 10:59 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f43f1c5a9909 Fix non-PCH build ! src/share/vm/code/debugInfo.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp Changeset: ed7754c15700 Author: shade Date: 2018-03-12 17:30 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ed7754c15700 [backport] Fix || and && chaining warnings in memnode.cpp ! src/share/vm/opto/memnode.cpp Changeset: 1bb8451d68f6 Author: roland Date: 2018-03-15 10:56 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1bb8451d68f6 [backport] fix for alias analysis with ShenandoahBarriersForConst ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 0d02a4042b61 Author: rkennke Date: 2018-03-15 19:52 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0d02a4042b61 [backport] FinalEvac pause to turn off evacuation ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.hpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 3be36b42b9c1 Author: rkennke Date: 2018-03-15 19:52 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3be36b42b9c1 [backport] Little cleanup ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: f2302e292f4d Author: shade Date: 2018-03-16 13:24 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f2302e292f4d [backport] Tax-and-Spend allocation pacing ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/options/TestPacing.java Changeset: a092f02dfc17 Author: shade Date: 2018-03-19 12:23 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a092f02dfc17 [backport] Rewire control loop to avoid double cleanup work ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp Changeset: 7743867b2691 Author: shade Date: 2018-03-19 12:36 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7743867b2691 [backport] Excessive asserts in marked_object_iterate ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 4fa677073730 Author: zgu Date: 2018-03-19 09:33 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4fa677073730 [backport] Added missing header file for non-PCH build ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp Changeset: 845bc57e0c96 Author: shade Date: 2018-03-19 14:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/845bc57e0c96 [backport] Provide non-taxable allocation slack at the beginning of the cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 6a6588123cf2 Author: shade Date: 2018-03-20 16:25 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6a6588123cf2 [backport] Full GC should not trash empty regions ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: d358d517e708 Author: shade Date: 2018-03-20 13:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d358d517e708 [backport] Rename and cleanup _regions and _free_set uses ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: 7a7217014e80 Author: rkennke Date: 2018-03-16 22:17 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7a7217014e80 [backport] Keep track of per-cycle mutator/collector allocs. Fix mutator/collector alloc region overlap in traversal. ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: b19a656d61e0 Author: zgu Date: 2018-03-26 09:47 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b19a656d61e0 [backport] Fixed missing ResourceMark in ShenandoahAsserts::print_obj ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp Changeset: 3c89e42a53a2 Author: zgu Date: 2018-03-28 16:27 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3c89e42a53a2 [backport] Shenandoah critical native support + Fixed critical native typo and test + Handle null critical native array ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp + test/gc/shenandoah/CriticalNativeArgs.java + test/gc/shenandoah/CriticalNativeArgs.sh + test/gc/shenandoah/CriticalNativeStress.java + test/gc/shenandoah/CriticalNativeStress.sh + test/gc/shenandoah/libCriticalNative.c Changeset: 091ad9e6fd67 Author: shade Date: 2018-03-28 23:02 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/091ad9e6fd67 [backport] UX: Shorter gc+ergo messages from CSet selection ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 66ed4a435658 Author: shade Date: 2018-03-28 23:02 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/66ed4a435658 [backport] UX: Pacer reports incorrect free size ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: f7d24b201efb Author: shade Date: 2018-03-28 23:02 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f7d24b201efb [backport] UX: Cleanup (adaptive) CSet selection message ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 969806e2ad00 Author: shade Date: 2018-03-28 23:02 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/969806e2ad00 [backport] Compact heuristics should not shortcut on immediate garbage, but aggressively compact ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: e20985bcbb76 Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e20985bcbb76 [backport] Cleanup SHH::should_start_normal_gc ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp Changeset: 73180b66bb2d Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/73180b66bb2d [backport] FreeSet and HeapRegion should have the reference to ShenandoahHeap ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 8f917a772b55 Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8f917a772b55 [backport] Refactor FreeSet rebuilding into the single source ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: ef4b4a130f02 Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ef4b4a130f02 [backport] FreeSet should accept responsibility over trashed regions ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 2248b6e5e413 Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2248b6e5e413 [backport] Drop distinction between immediate garbage and free in heuristics ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 392b0d5622c6 Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/392b0d5622c6 [backport] Do not add non-allocatable regions to the freeset ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp Changeset: 25ae09315e05 Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/25ae09315e05 [backport] Pacer should poll FreeSet to figure out actually available space ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 34b0a072bc0d Author: shade Date: 2018-03-29 14:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/34b0a072bc0d [backport] Remove FreeSet::add_region, inline into FreeSet::rebuild ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp Changeset: b9b7f8909ab1 Author: shade Date: 2018-03-29 16:01 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b9b7f8909ab1 [backport] Remove obsolete check in FreeSet::allocate ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: 89aa5f8d2152 Author: zgu Date: 2018-04-04 09:17 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/89aa5f8d2152 [backport] Adapt upstream object pinning API ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 2add52cf9df2 Author: shade Date: 2018-04-05 10:54 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2add52cf9df2 [backport] Remove CSetThreshold handling from heuristics ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 5114410c2684 Author: shade Date: 2018-04-05 17:04 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5114410c2684 [backport] Pacer should account allocation waste and unsuccessful pacing in the budget ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp Changeset: ff6b600f0a9a Author: shade Date: 2018-04-06 17:13 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ff6b600f0a9a [backport] Move ShHeap::used increment out of locked allocation path ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: fabe9c0011da Author: shade Date: 2018-04-06 17:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fabe9c0011da [backport] Avoid notifying about zero waste ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: 9f3874e1b6ba Author: shade Date: 2018-04-11 11:43 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9f3874e1b6ba [backport] Immediate garbage ratio should not go over 100% ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 52931dd0fd22 Author: shade Date: 2018-04-11 19:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/52931dd0fd22 [backport] Introduce assert_in_correct_region to verify object is in correct region ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp Changeset: 14a00ec95e32 Author: shade Date: 2018-04-12 10:21 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/14a00ec95e32 [backport] FreeSet should report its internal state before/after GC cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp Changeset: 496722dc2ec0 Author: shade Date: 2018-04-12 10:53 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/496722dc2ec0 [backport] Disambiguate "upgrade to Full GC" GCause ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 6d1b25638e1b Author: shade Date: 2018-04-12 11:31 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6d1b25638e1b [backport] Report how much we have failed to allocate during Allocation Failure ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 2f1da6e6d006 Author: rkennke Date: 2018-04-12 14:49 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2f1da6e6d006 [backport] Use/sort (cached) RegionData not ShenandoahHeapRegionSet (infrastructure) ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp Changeset: 908723b9f760 Author: sangheki Date: 2017-02-09 19:08 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/908723b9f760 Cherry-pick JDK-8173013: JVMTI tagged object access needs G1 pre-barrier ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 388a0e0523c2 Author: mdoerr Date: 2016-09-06 13:01 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/388a0e0523c2 Cherry-pick JDK-8165489: Missing G1 barrier in Unsafe_GetObjectVolatile ! src/share/vm/prims/unsafe.cpp Changeset: ea3ab1a51237 Author: shade Date: 2018-02-07 21:53 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ea3ab1a51237 Cherry-pick JDK-8187577: JVM crash during gc doing concurrent marking ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp Changeset: a47efd5b4762 Author: shade Date: 2018-04-12 14:07 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a47efd5b4762 [backport] Only report GC pause time to GC MXBean + Re-fix memory managers and memory pools usage and pause reporting ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/shenandoahMemoryPool.cpp ! src/share/vm/services/shenandoahMemoryPool.hpp ! test/TEST.groups - test/gc/shenandoah/MXNotificationsFullGC.java + test/gc/shenandoah/mxbeans/ChurnNotifications.java + test/gc/shenandoah/mxbeans/PauseNotifications.java Changeset: 53d90b8cdb69 Author: shade Date: 2018-04-13 10:50 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/53d90b8cdb69 [backport] Add test to verify Shenandoah is not enabled by default, and enabled with the flag + test/gc/shenandoah/options/TestEnabled.java Changeset: 02493b224a7d Author: shade Date: 2018-04-16 12:35 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/02493b224a7d [backport] Basic support for x86_32: build and run in STW configuration ! src/share/vm/runtime/arguments.cpp Changeset: 69563f0acd3c Author: rkennke Date: 2018-04-16 13:58 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/69563f0acd3c [backport] Bitmap based ShHeapRegionSet ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: 52a4ce092c9c Author: shade Date: 2018-04-25 09:48 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/52a4ce092c9c Fix non-PCH x86_32 build ! src/share/vm/runtime/arguments.cpp Changeset: 4b42b8e862aa Author: shade Date: 2018-04-27 16:02 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4b42b8e862aa [backport] Testbug: VerifyJCStressTest leaks memory ! test/gc/shenandoah/acceptance/VerifyJCStressTest.java Changeset: 34f1e8af32df Author: rkennke Date: 2018-04-23 18:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/34f1e8af32df [backport] Remove ShenandoahMarkCompactBarrierSet ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: ca05f5895360 Author: shade Date: 2018-04-24 10:07 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ca05f5895360 [backport] Isolate shenandoahVerifier from stray headers ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 5a41ffb32802 Author: shade Date: 2018-04-25 15:57 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5a41ffb32802 [backport] Wipe out ShenandoahStoreCheck implementation ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! 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 ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad Changeset: 1b50ef62f1af Author: rkennke Date: 2018-04-26 10:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1b50ef62f1af [backport] Fix broken asserts in ShenandoahSharedEnumFlag ! src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp Changeset: 2cb01778a773 Author: rkennke Date: 2018-04-26 21:31 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2cb01778a773 [backport] Some smallish ShHeapRegionSet changes ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp Changeset: 4adee0dbe7d3 Author: shade Date: 2018-04-27 11:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4adee0dbe7d3 [backport] Shenandoah/SPARC barrier stubs ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp Changeset: ef78be738640 Author: shade Date: 2018-04-27 11:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ef78be738640 [backport] Shenandoah/Zero barrier stubs + src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp Changeset: 5a04995cf717 Author: shade Date: 2018-05-01 11:24 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5a04995cf717 Fix up SPARC and Zero headers for proper locations ! src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp ! src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp Changeset: 6b8394a6997c Author: shade Date: 2018-05-02 21:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6b8394a6997c [backport] Shenandoah region/set iterators should not allow copying ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: ea06d761529e Author: shade Date: 2018-05-03 13:39 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ea06d761529e [backport] Set ShenandoahMinFreeThreshold default to 10% ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 3a2688e08fbd Author: zgu Date: 2018-05-04 12:38 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3a2688e08fbd [backport] Critical native tests should only be ran on x86_64 platforms ! test/gc/shenandoah/CriticalNativeArgs.sh ! test/gc/shenandoah/CriticalNativeStress.sh Changeset: 8362528c4a90 Author: shade Date: 2018-05-07 12:00 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8362528c4a90 [backport] Fix Minimal VM build ! make/excludeSrc.make ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.inline.hpp Changeset: 82e4fdb9d63c Author: zgu Date: 2018-05-08 09:02 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/82e4fdb9d63c [backport] Fixing Windows and ARM32 build ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 62edad03fdf3 Author: rkennke Date: 2018-05-11 15:56 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/62edad03fdf3 [backport] Fix ShFreeSet boundary case ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: fdb6f8c59f16 Author: zgu Date: 2018-05-11 16:44 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fdb6f8c59f16 [backport] Cleanup: removed unused code ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: 8da3726955aa Author: shade Date: 2018-05-15 10:09 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8da3726955aa [backport] Rename ShenandoahConcurrentThread to ShenandoahControlThread - src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/runtime/thread.cpp Changeset: 82817303b6fd Author: rkennke Date: 2018-05-08 19:50 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/82817303b6fd [backport] Break heuristics out from ShCollectorPolicy into their own source files + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 6cc4d48008b0 Author: shade Date: 2018-05-15 13:56 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6cc4d48008b0 Fix AArch64 build failure: misplaced #endif ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Changeset: e7dad6cabd1a Author: zgu Date: 2018-05-16 14:30 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e7dad6cabd1a Fixed Shenandoah 8u build ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 67e063d99bbd Author: rkennke Date: 2018-06-06 11:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/67e063d99bbd Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 for changeset e7dad6cabd1a ! .hgtags From stuart.monteith at linaro.org Wed Jun 6 10:18:37 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 6 Jun 2018 11:18:37 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> Message-ID: Hi, The builds are failing with some simple jtreg failures - and not issues with ZGC as I first thought. The results are here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/149/summary.html I spent a little time reproducing the results on a recent build - today and yesterday. Disabling/Enabling "UseBarriersForVolatile" makes no difference. I am testing with fastdebug and on the C1 compiler. These failures don't appear with C2. BR, Stuart On 5 June 2018 at 17:37, Andrew Haley wrote: > On 06/05/2018 05:25 PM, Roman Kennke wrote: >> Is anybody working on this? It blocks my testing on other unrelated >> patches and generally makes CI unhappy on aarch64. > > I'm waiting for Andrew Dinn to return. It's his code that was > broken by the modular GC barriers change. > > In the meantime you can set UseBarriersForVolatile to true. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 11:16:18 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 06 Jun 2018 15:16:18 +0400 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> Message-ID: <5B17C282.6030009@bell-sw.com> 06.06.2018 12:23, Andrew Haley ?????: > On 06/06/2018 08:59 AM, Andrew Haley wrote: >> On 06/05/2018 08:46 PM, Dmitrij Pochepko wrote: >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.01/ >> >> OK, seems reasonable. > > Hold on, no. I replied too quickly. > > 2572 void MacroAssembler::push_call_clobbered_registers() { > 2573 int step = 4 * wordSize; > 2574 push(RegSet::range(r0, r18) - RegSet::of(rscratch1, rscratch2), sp); > 2575 sub(sp, sp, step); > 2576 mov(rscratch1, -step); > 2577 // Push v0-v7, v16-v31. > 2578 for (int i = 31; i>= 4; i -= 4) { > 2579 if (i <= v7->encoding() || i >= v16->encoding()) > 2580 st1(as_FloatRegister(i-3), as_FloatRegister(i-2), as_FloatRegister(i-1), > 2581 as_FloatRegister(i), T1D, Address(sp, rscratch1)); > > 2582 } > 2583 st1(as_FloatRegister(0), as_FloatRegister(1), as_FloatRegister(2), > 2584 as_FloatRegister(3), T1D, Address(sp)); > 2585 } > > What is "step" in rscratch1 used for here? Where do we push the registers? > You're probably referring to confusing addressing notation here. I was confused originally as well. According to AARCH64 specification, ld* and st* instructions has 3 addressing modes: 1) base register, no offset 2) post-index, immediate value 3) post-index, register value (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) Address class was designed with post-index to be an immediate values, so, that is probably why "register post-index" mode for ld/st is using regular "register offset" mode, treating it as "register post-index". My patch is using this "register post-index" mode to have less instructions generated. I was a bit confused when first tried to use this mode and found such specifics. I had to recheck specific instruction generation code to be sure. Thanks, Dmitrij From aph at redhat.com Wed Jun 6 11:38:14 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 12:38:14 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> Message-ID: On 06/06/2018 11:18 AM, Stuart Monteith wrote: > The builds are failing with some simple jtreg failures - and not > issues with ZGC as I first thought. > > The results are here: > http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/149/summary.html > > I spent a little time reproducing the results on a recent build - > today and yesterday. Disabling/Enabling "UseBarriersForVolatile" makes > no difference. > I am testing with fastdebug and on the C1 compiler. These failures > don't appear with C2. OK, so that's a different but from the one that Zhongwei fixed, then. -- 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 Wed Jun 6 11:39:40 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 12:39:40 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> Message-ID: <6c082b58-d3e3-68f9-ce50-7be4ed330a44@redhat.com> On 06/06/2018 11:18 AM, Stuart Monteith wrote: > Hi, > The builds are failing with some simple jtreg failures - and not > issues with ZGC as I first thought. > > The results are here:> http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/149/summary.html The requested URL /jdkX/openjdk-jtreg-nightly-tests/builds/client-release/2018/149/JTwork-hotspot/scratch/3/hs_err_pid11249.log was not found on this server. > > I spent a little time reproducing the results on a recent build - > today and yesterday. Disabling/Enabling "UseBarriersForVolatile" makes > no difference. > I am testing with fastdebug and on the C1 compiler. These failures > don't appear with C2. > > BR, > Stuart > > On 5 June 2018 at 17:37, Andrew Haley wrote: >> On 06/05/2018 05:25 PM, Roman Kennke wrote: >>> Is anybody working on this? It blocks my testing on other unrelated >>> patches and generally makes CI unhappy on aarch64. >> >> I'm waiting for Andrew Dinn to return. It's his code that was >> broken by the modular GC barriers change. >> >> In the meantime you can set UseBarriersForVolatile to true. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- 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 Wed Jun 6 11:41:20 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 12:41:20 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: <5B17C282.6030009@bell-sw.com> References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 12:16 PM, Dmitrij Pochepko wrote: > You're probably referring to confusing addressing notation here. I was > confused originally as well. > > According to AARCH64 specification, ld* and st* instructions has 3 > addressing modes: > 1) base register, no offset > 2) post-index, immediate value > 3) post-index, register value > (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) > > Address class was designed with post-index to be an immediate values, > so, that is probably why "register post-index" mode for ld/st is using > regular "register offset" mode, treating it as "register post-index". > > My patch is using this "register post-index" mode to have less > instructions generated. I was a bit confused when first tried to use > this mode and found such specifics. I had to recheck specific > instruction generation code to be sure. Oh no, that is too horrible. We must fix that before using this addressing mode for anything else. -- 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 Wed Jun 6 12:15:26 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 13:15:26 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 12:41 PM, Andrew Haley wrote: > On 06/06/2018 12:16 PM, Dmitrij Pochepko wrote: >> You're probably referring to confusing addressing notation here. I was >> confused originally as well. >> >> According to AARCH64 specification, ld* and st* instructions has 3 >> addressing modes: >> 1) base register, no offset >> 2) post-index, immediate value >> 3) post-index, register value >> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) >> >> Address class was designed with post-index to be an immediate values, >> so, that is probably why "register post-index" mode for ld/st is using >> regular "register offset" mode, treating it as "register post-index". >> >> My patch is using this "register post-index" mode to have less >> instructions generated. I was a bit confused when first tried to use >> this mode and found such specifics. I had to recheck specific >> instruction generation code to be sure. > > Oh no, that is too horrible. We must fix that before using this > addressing mode for anything else. But is it even true? I just grepped for st1 and I can find no examples of it being used in that way. Are there any? I do see this, which looks fine: st1(Vtmp1, Vtmp2, T16B, post(dst, 32)); -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 12:30:32 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 15:30:32 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06.06.2018 15:15, Andrew Haley wrote: > On 06/06/2018 12:41 PM, Andrew Haley wrote: >> On 06/06/2018 12:16 PM, Dmitrij Pochepko wrote: >>> You're probably referring to confusing addressing notation here. I was >>> confused originally as well. >>> >>> According to AARCH64 specification, ld* and st* instructions has 3 >>> addressing modes: >>> 1) base register, no offset >>> 2) post-index, immediate value >>> 3) post-index, register value >>> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LD1_advsimd_sngl_vector.html) >>> >>> Address class was designed with post-index to be an immediate values, >>> so, that is probably why "register post-index" mode for ld/st is using >>> regular "register offset" mode, treating it as "register post-index". >>> >>> My patch is using this "register post-index" mode to have less >>> instructions generated. I was a bit confused when first tried to use >>> this mode and found such specifics. I had to recheck specific >>> instruction generation code to be sure. >> Oh no, that is too horrible. We must fix that before using this >> addressing mode for anything else. > But is it even true? I just grepped for st1 and I can find no examples > of it being used in that way. Are there any? I do see this, which looks > fine: > > st1(Vtmp1, Vtmp2, T16B, post(dst, 32)); > I believe I'm the first one to use ld/st with register post-index addressing mode in hotspot. You can take a look here: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 As you can see, switch by a.getMode() has 3 cases: 1) "base_plus_offset" (expecting only 0 offset. This is for "base register, no offset" ld/st addressing mode 2) "post"- this if for immediate post-index mode 3) "base_plus_offset_reg" which is treated further as register post-index mode. I'll create separate issue and patch, which will add new address mode (something like: "post_reg"). And final syntax for such mode usage will be ... Address(post(, )), which makes it more readable. After that I'll update this fpu ld/st optimization patch accordingly. How about that? Thanks, Dmitrij From aph at redhat.com Wed Jun 6 12:37:07 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 13:37:07 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 01:30 PM, Dmitrij Pochepko wrote: > You can take a look here: > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 > As you can see, switch by a.getMode() has 3 cases: > > 1) "base_plus_offset" (expecting only 0 offset. This is for "base > register, no offset" ld/st addressing mode > 2) "post"- this if for immediate post-index mode > 3) "base_plus_offset_reg" which is treated further as register > post-index mode. Well, yes, but I can't see that being [ab]used anywhere in the existing source. > I'll create separate issue and patch, which will add new address mode > (something like: "post_reg"). And final syntax for such mode usage will > be ... Address(post(, )), which makes it more readable. Yes. And please disallow the use of Address(reg, reg) while you're doing that. > After that I'll update this fpu ld/st optimization patch accordingly. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 13:33:36 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 16:33:36 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly Message-ID: Hi all, please review patch for: JDK-8204473 -? AARCH64: register post-index addressing mode is not supported directly This patch adds new addressing mode: "post_reg"? (register post-index) with respective changes in code. It is used for ld* and st* instructions. Before this patch, this mode could be enabled by using base_plus_offset_reg, which makes code confusing. Testing: I launched hotspot jtreg compiler tests to ensure nothing is broken. No new failures found. webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8204473 Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 6 13:43:38 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 16:43:38 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06.06.2018 15:37, Andrew Haley wrote: > On 06/06/2018 01:30 PM, Dmitrij Pochepko wrote: >> You can take a look here: >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 >> As you can see, switch by a.getMode() has 3 cases: >> >> 1) "base_plus_offset" (expecting only 0 offset. This is for "base >> register, no offset" ld/st addressing mode >> 2) "post"- this if for immediate post-index mode >> 3) "base_plus_offset_reg" which is treated further as register >> post-index mode. > Well, yes, but I can't see that being [ab]used anywhere in the existing > source. > >> I'll create separate issue and patch, which will add new address mode >> (something like: "post_reg"). And final syntax for such mode usage will >> be ... Address(post(, )), which makes it more readable. > Yes. And please disallow the use of Address(reg, reg) while you're doing > that. > >> After that I'll update this fpu ld/st optimization patch accordingly. > OK. > Please take a look at webrev.02: http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ The only change is to match changes in JDK-8204473 -? AARCH64: register post-index addressing mode is not supported directly 2 entries of "Address(sp, rscratch1)" is now "Address(post(sp, rscratch1))" I relaunched hotspot jtreg compiler tests as sanity with both patches. No new failures found. Thanks, Dmitrij From aph at redhat.com Wed Jun 6 16:37:03 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 17:37:03 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: Message-ID: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> On 06/06/2018 02:33 PM, Dmitrij Pochepko wrote: > Hi all, > > please review patch for: JDK-8204473 -? AARCH64: register post-index > addressing mode is not supported directly > > This patch adds new addressing mode: "post_reg"? (register post-index) > with respective changes in code. It is used for ld* and st* > instructions. Before this patch, this mode could be enabled by using > base_plus_offset_reg, which makes code confusing. > > > Testing: I launched hotspot jtreg compiler tests to ensure nothing is > broken. No new failures found. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8204473 Did you run a debug build? # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_aarch64.hpp:2089 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/local/jdk-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2089), pid=31485, tid=31486 # Error: ShouldNotReachHere() # # JRE version: (11.0) (slowdebug build ) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-aarch64) # Core dump will be written. Default location: /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/core.31485 # # An error report file with more information is saved as: # /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/hs_err_pid31485.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 31486 Dumping core ... -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 16:59:13 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 19:59:13 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> Message-ID: On 06.06.2018 19:37, Andrew Haley wrote: > On 06/06/2018 02:33 PM, Dmitrij Pochepko wrote: >> Hi all, >> >> please review patch for: JDK-8204473 -? AARCH64: register post-index >> addressing mode is not supported directly >> >> This patch adds new addressing mode: "post_reg"? (register post-index) >> with respective changes in code. It is used for ld* and st* >> instructions. Before this patch, this mode could be enabled by using >> base_plus_offset_reg, which makes code confusing. >> >> >> Testing: I launched hotspot jtreg compiler tests to ensure nothing is >> broken. No new failures found. >> >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8204473 > Did you run a debug build? > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_aarch64.hpp:2089 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/local/jdk-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2089), pid=31485, tid=31486 > # Error: ShouldNotReachHere() > # > # JRE version: (11.0) (slowdebug build ) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-aarch64) > # Core dump will be written. Default location: /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/core.31485 > # > # An error report file with more information is saved as: > # /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/hs_err_pid31485.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Current thread is 31486 > Dumping core ... > Ahh, sorry. Missed single existing [ab]usage of such addressing in fastdebug mode: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 However, there is a confusing comment there: "// BEGIN? Generated code -- do not edit // Generated by aarch64-asmtest.py" What should we do about it? I don't see aarch64-asmtest.py to edit. Do we need to edit this smoke test directly despite this comment? Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 6 17:14:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 20:14:12 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> Message-ID: <0a44de57-d2ce-8386-ed82-0ab34d40479f@bell-sw.com> On 06.06.2018 19:59, Dmitrij Pochepko wrote: > > > On 06.06.2018 19:37, Andrew Haley wrote: >> On 06/06/2018 02:33 PM, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> please review patch for: JDK-8204473 -? AARCH64: register post-index >>> addressing mode is not supported directly >>> >>> This patch adds new addressing mode: "post_reg"? (register post-index) >>> with respective changes in code. It is used for ld* and st* >>> instructions. Before this patch, this mode could be enabled by using >>> base_plus_offset_reg, which makes code confusing. >>> >>> >>> Testing: I launched hotspot jtreg compiler tests to ensure nothing is >>> broken. No new failures found. >>> >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.01/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8204473 >> Did you run a debug build? >> >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: >> SuppressErrorAt=/assembler_aarch64.hpp:2089 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> #? Internal Error >> (/local/jdk-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2089), >> pid=31485, tid=31486 >> #? Error: ShouldNotReachHere() >> # >> # JRE version:? (11.0) (slowdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug >> 11-internal+0-adhoc.aph.jdk-jdk, mixed mode, aot, sharing, tiered, >> compressed oops, g1 gc, linux-aarch64) >> # Core dump will be written. Default location: >> /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/core.31485 >> # >> # An error report file with more information is saved as: >> # >> /local/jdk-jdk/build/linux-aarch64-normal-server-slowdebug/jdk/bin/hs_err_pid31485.log >> # >> # If you would like to submit a bug report, please visit: >> #?? http://bugreport.java.com/bugreport/crash.jsp >> # >> Current thread is 31486 >> Dumping core ... >> > Ahh, sorry. Missed single existing [ab]usage of such addressing in > fastdebug mode: > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 > > However, there is a confusing comment there: "// BEGIN? Generated code > -- do not edit // Generated by aarch64-asmtest.py" > What should we do about it? I don't see aarch64-asmtest.py to edit. Do > we need to edit this smoke test directly despite this comment? > > Thanks, > Dmitrij ... there is still // END Generated code comment above, but I don't know, if aarch64-asmtest.py (if any will be ever used) will append hand-written code to a generated one. In that case, where it takes this code to append? Or it is safe to edit? Thanks, Dmitrij From aph at redhat.com Wed Jun 6 17:16:23 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Jun 2018 18:16:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> Message-ID: <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: > Ahh, sorry. Missed single existing [ab]usage of such addressing in > fastdebug mode: Mmm. It's always a really, really good idea to run tests with assertions enabled. > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 > > However, there is a confusing comment there: "// BEGIN Generated code > -- do not edit // Generated by aarch64-asmtest.py" > What should we do about it? I don't see aarch64-asmtest.py to edit. Oh yes. It must not have been included when we merged into mainline. Oops. > Do we need to edit this smoke test directly despite this comment? Yes, please. The code you need to edit is *after* the line END Generated code -- do not edit I did this: address PC = __ pc(); __ ld1(v0, __ T16B, Address(r16)); // No offset __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index __ ld1(v0, __ T16B, __ post(r16, r17)); // which at least checks that we can generate the instructions, for which I get 0x000003ffa1000764: ld1 {v0.16b}, [x16] 0x000003ffa1000768: ld1 {v0.16b}, [x16], #16 0x000003ffa100076c: ld1 {v0.16b}, [x16], x17 That "#16" looks odd. Presumably there's some scaling going on there. Do you know? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 6 17:26:42 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 20:26:42 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> Message-ID: On 06.06.2018 20:16, Andrew Haley wrote: > On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: >> Ahh, sorry. Missed single existing [ab]usage of such addressing in >> fastdebug mode: > Mmm. It's always a really, really good idea to run tests with > assertions enabled. Yes. My bad. >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 >> >> However, there is a confusing comment there: "// BEGIN Generated code >> -- do not edit // Generated by aarch64-asmtest.py" >> What should we do about it? I don't see aarch64-asmtest.py to edit. > Oh yes. It must not have been included when we merged into mainline. > Oops. > >> Do we need to edit this smoke test directly despite this comment? > Yes, please. The code you need to edit is *after* the line > END Generated code -- do not edit Thanks. Running full test cycle now. > > I did this: > > address PC = __ pc(); > __ ld1(v0, __ T16B, Address(r16)); // No offset > __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index > __ ld1(v0, __ T16B, __ post(r16, r17)); // > > which at least checks that we can generate the instructions, for which > I get > > 0x000003ffa1000764: ld1 {v0.16b}, [x16] > 0x000003ffa1000768: ld1 {v0.16b}, [x16], #16 > 0x000003ffa100076c: ld1 {v0.16b}, [x16], x17 > > That "#16" looks odd. Presumably there's some scaling going on there. > Do you know? > Yes. I also investigated this some time ago. It is also related to ld/st addressing modes. For immediate post-index of ld/st only one immediate value per type is supported (which is size of loaded/stored data) and the instruction doesn't allow any other options for immediates (see specification, C7.2.152 LD1 (multiple structures)). So, hotspot just checks if immediate is not zero and silently generates the instruction. Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 6 17:46:23 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 20:46:23 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> Message-ID: <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> On 06.06.2018 20:26, Dmitrij Pochepko wrote: > > > On 06.06.2018 20:16, Andrew Haley wrote: >> On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: >>> Ahh, sorry. Missed single existing [ab]usage of such addressing in >>> fastdebug mode: >> Mmm.? It's always a really, really good idea to run tests with >> assertions enabled. > Yes. My bad. >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 >>> >>> >>> However, there is a confusing comment there: "// BEGIN Generated code >>> -- do not edit // Generated by aarch64-asmtest.py" >>> What should we do about it? I don't see aarch64-asmtest.py to edit. >> Oh yes.? It must not have been included when we merged into mainline. >> Oops. >> >>> Do we need to edit this smoke test directly despite this comment? >> Yes, please.? The code you need to edit is *after* the line >> END? Generated code -- do not edit > Thanks. Running full test cycle now. >> >> I did this: >> >> ?? address PC = __ pc(); >> ?? __ ld1(v0, __ T16B, Address(r16)); // No offset >> ?? __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index >> ?? __ ld1(v0, __ T16B, __ post(r16, r17)); // >> >> which at least checks that we can generate the instructions, for which >> I get >> >> ?? 0x000003ffa1000764: ld1??? {v0.16b}, [x16] >> ?? 0x000003ffa1000768: ld1??? {v0.16b}, [x16], #16 >> ?? 0x000003ffa100076c: ld1??? {v0.16b}, [x16], x17 >> >> That "#16" looks odd.? Presumably there's some scaling going on there. >> Do you know? >> > Yes. I also investigated this some time ago. It is also related to > ld/st addressing modes. > For immediate post-index of ld/st only one immediate value per type is > supported (which is size of loaded/stored data) and the instruction > doesn't allow any other options for immediates (see specification, > C7.2.152 > LD1 (multiple structures)). > So, hotspot just checks if immediate is not zero and silently > generates the instruction. > > Thanks, > Dmitrij Please take a look to webrev.02: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.02/ Simple sanity with fastdebug build passed. Currently waiting for large test cycle to be finished. Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 6 18:33:31 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 6 Jun 2018 21:33:31 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> Message-ID: <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> On 06.06.2018 20:46, Dmitrij Pochepko wrote: > > > On 06.06.2018 20:26, Dmitrij Pochepko wrote: >> >> >> On 06.06.2018 20:16, Andrew Haley wrote: >>> On 06/06/2018 05:59 PM, Dmitrij Pochepko wrote: >>>> Ahh, sorry. Missed single existing [ab]usage of such addressing in >>>> fastdebug mode: >>> Mmm.? It's always a really, really good idea to run tests with >>> assertions enabled. >> Yes. My bad. >>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l1179 >>>> >>>> >>>> However, there is a confusing comment there: "// BEGIN Generated code >>>> -- do not edit // Generated by aarch64-asmtest.py" >>>> What should we do about it? I don't see aarch64-asmtest.py to edit. >>> Oh yes.? It must not have been included when we merged into mainline. >>> Oops. >>> >>>> Do we need to edit this smoke test directly despite this comment? >>> Yes, please.? The code you need to edit is *after* the line >>> END? Generated code -- do not edit >> Thanks. Running full test cycle now. >>> >>> I did this: >>> >>> ?? address PC = __ pc(); >>> ?? __ ld1(v0, __ T16B, Address(r16)); // No offset >>> ?? __ ld1(v0, __ T16B, __ post(r16, 8)); // Post-index >>> ?? __ ld1(v0, __ T16B, __ post(r16, r17)); // >>> >>> which at least checks that we can generate the instructions, for which >>> I get >>> >>> ?? 0x000003ffa1000764: ld1??? {v0.16b}, [x16] >>> ?? 0x000003ffa1000768: ld1??? {v0.16b}, [x16], #16 >>> ?? 0x000003ffa100076c: ld1??? {v0.16b}, [x16], x17 >>> >>> That "#16" looks odd.? Presumably there's some scaling going on there. >>> Do you know? >>> >> Yes. I also investigated this some time ago. It is also related to >> ld/st addressing modes. >> For immediate post-index of ld/st only one immediate value per type >> is supported (which is size of loaded/stored data) and the >> instruction doesn't allow any other options for immediates (see >> specification, C7.2.152 >> LD1 (multiple structures)). >> So, hotspot just checks if immediate is not zero and silently >> generates the instruction. >> >> Thanks, >> Dmitrij > > Please take a look to webrev.02: > http://cr.openjdk.java.net/~dpochepk/8204473/webrev.02/ > Simple sanity with fastdebug build passed. Currently waiting for large > test cycle to be finished. > > Thanks, > Dmitrij large test cycle passed. no new failures(although lots of JDK-8204331 failures). From Derek.White at cavium.com Wed Jun 6 22:33:00 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 6 Jun 2018 22:33:00 +0000 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: <5d5e6c96-239c-557d-d2f1-4be377b83935@redhat.com> References: <5d5e6c96-239c-557d-d2f1-4be377b83935@redhat.com> Message-ID: Hi Andrew, Sorry, I've been staring at the JDK 9 code for the last few weeks. This issue was fixed in JDK 10. Dmitrij, it looks like there's a similar fix possible to save_live_registers()/restore_live_registers() in c1_Runtime1_aarch64.cpp. It's used in about 24 stubs. I think this current fix is fine as is, but you might consider save_live_registers() as a separate fix when you (or someone) gets the time. Sorry for hijacking this RFR! - Derek > -----Original Message----- > On 06/05/2018 10:48 PM, White, Derek wrote: > > > The related question I've had on the back-burner for a while is WHY > > are we saving/restoring 42 registers in > > gen_write_ref_array_pre_barrier/ gen_write_ref_array_post_barrier? > > Please point me to the exact line of code you are talking about. > > We don't do that around any other calls to call_VM_leaf. > > > > No other port saves the entire register set, even the arm64 port. They > > just save a few registers that are in use. > > You don't know which registers are in use. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Wed Jun 6 23:18:21 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 6 Jun 2018 23:18:21 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <790148466.589.1528327102388.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/156/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/07 pass: 1,675; fail: 14; error: 2; not run: 11,615 Build 1: aarch64/2018/apr/15 pass: 1,674; fail: 14; error: 2; not run: 11,615 Build 2: aarch64/2018/apr/17 pass: 1,675; fail: 14; error: 1; not run: 11,615 Build 3: aarch64/2018/may/10 pass: 3,190; fail: 14; error: 3; not run: 11,616 Build 4: aarch64/2018/may/11 pass: 3,192; fail: 12; error: 3; not run: 11,616 Build 5: aarch64/2018/may/13 pass: 3,191; fail: 13; error: 3; not run: 11,616 Build 6: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 7: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 8: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 9: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 10: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 11: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 12: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 13: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 14: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/07 pass: 7,781; fail: 632; error: 18 Build 1: aarch64/2018/apr/15 pass: 7,824; fail: 583; error: 29 Build 2: aarch64/2018/apr/17 pass: 7,800; fail: 621; error: 15 Build 3: aarch64/2018/may/10 pass: 7,905; fail: 595; error: 22 Build 4: aarch64/2018/may/11 pass: 7,880; fail: 623; error: 19 Build 5: aarch64/2018/may/13 pass: 7,903; fail: 599; error: 23 Build 6: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 7: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 8: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 9: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 10: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 11: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 12: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 13: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 14: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/07 pass: 3,851; fail: 6; error: 3 Build 1: aarch64/2018/apr/15 pass: 3,855; fail: 6; error: 3 Build 2: aarch64/2018/apr/17 pass: 3,856; fail: 6; error: 2 Build 3: aarch64/2018/may/10 pass: 3,865; fail: 6 Build 4: aarch64/2018/may/11 pass: 3,865; fail: 6 Build 5: aarch64/2018/may/13 pass: 3,862; fail: 6; error: 4 Build 6: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 7: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 8: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 9: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 10: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 11: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 12: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 13: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 14: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/07 pass: 1,685; fail: 13; not run: 11,615 Build 1: aarch64/2018/apr/15 pass: 1,682; fail: 13; error: 2; not run: 11,615 Build 2: aarch64/2018/apr/17 pass: 1,682; fail: 14; error: 1; not run: 11,615 Build 3: aarch64/2018/may/10 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 4: aarch64/2018/may/11 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 5: aarch64/2018/may/13 pass: 3,200; fail: 11; error: 3; not run: 11,616 Build 6: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 7: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 8: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 9: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 10: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 11: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 12: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/07 pass: 7,797; fail: 619; error: 15 Build 1: aarch64/2018/apr/15 pass: 7,849; fail: 560; error: 27 Build 2: aarch64/2018/apr/17 pass: 7,825; fail: 593; error: 18 Build 3: aarch64/2018/may/10 pass: 7,918; fail: 586; error: 18 Build 4: aarch64/2018/may/11 pass: 7,912; fail: 592; error: 18 Build 5: aarch64/2018/may/13 pass: 7,892; fail: 616; error: 17 Build 6: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 7: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 8: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 9: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 10: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 11: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 12: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 13: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 14: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/07 pass: 3,853; fail: 5; error: 2 Build 1: aarch64/2018/apr/15 pass: 3,854; fail: 6; error: 4 Build 2: aarch64/2018/apr/17 pass: 3,854; fail: 6; error: 4 Build 3: aarch64/2018/may/10 pass: 3,862; fail: 6; error: 3 Build 4: aarch64/2018/may/11 pass: 3,860; fail: 6; error: 5 Build 5: aarch64/2018/may/13 pass: 3,861; fail: 6; error: 5 Build 6: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 7: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 8: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 9: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 10: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 11: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 12: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 13: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 14: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 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): 0.66x Relative performance: Server critical-jOPS (nc): 0.53x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.9, Server: 105.34 Client 66.9 / Client 2014-04-01 (43.00): 1.56x Server 105.34 / Server 2014-04-01 (71.00): 1.48x 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 15 days. 2018-04-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/097/results/ 2018-04-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/105/results/ 2018-04-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/107/results/ 2018-05-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/130/results/ 2018-05-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/131/results/ 2018-05-14 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/133/results/ 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From gil at azul.com Thu Jun 7 04:23:29 2018 From: gil at azul.com (Gil Tene) Date: Thu, 7 Jun 2018 04:23:29 +0000 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: This makes sense to me on the Aarch64 side. However, on the ARM32 side, I don't think the situation is as straightforward as what is being presented below, and I think more discussion and exploration of alternatives is needed. Much like with AArch64, there is an existing, active, community-developed and community-supported AArch32 port in OpenJDK that predates Oracle's open sourcing of their ARM32 version. That port is being used by multiple downstream builds and, at least for the past year+, it seems to have had more attention and ongoing engineering commitment around it than the Oracle variant. Before making a choice of one AArch32 port vs the other (if such a choice even needs to be made), I would like to hear more about the resources being committed towards maintaining each, keeping each up to date, testing them on various platforms (e.g. including building, testing, and supporting the popular softfloat ABI variants imposed by some OS packages) and working on bug fixes as needs appear. ? Gil. > On Jun 4, 2018, at 6:24 PM, David Holmes wrote: > > Hi Bob, > > Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. > > I think this is a good idea. > > Thanks, > David > > On 5/06/2018 6:34 AM, Bob Vandette wrote: >> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >> ARM ports and contributed them to OpenJDK. These ports have been used for >> years in the embedded and mobile market, making them very stable and >> having the benefit of a single source base which can produce both 32 and >> 64-bit binaries. The downside of this contribution is that it resulted >> in two 64-bit ARM implementations being available in OpenJDK. >> I'd like to propose that we eliminate one of the 64-bit ARM ports and >> encourage everyone to enhance and support the remaining 32 and 64 bit >> ARM ports. This would avoid the creation of yet another port for these chip >> architectures. The reduction of competing ports will allow everyone >> to focus their attention on a single 64-bit port rather than diluting >> our efforts. This will result in a higher quality and a more performant >> implementation. >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features. As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic. This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. >> Let me know what you all think, >> Bob Vandette From david.holmes at oracle.com Thu Jun 7 04:56:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Jun 2018 14:56:08 +1000 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> Hi Gil, On 7/06/2018 2:23 PM, Gil Tene wrote: > This makes sense to me on the Aarch64 side. > > However, on the ARM32 side, I don't think the situation is as straightforward as > what is being presented below, and I think more discussion and exploration of > alternatives is needed. > > Much like with AArch64, there is an existing, active, community-developed and > community-supported AArch32 port in OpenJDK that predates Oracle's open > sourcing of their ARM32 version. That port is being used by multiple downstream > builds and, at least for the past year+, it seems to have had more attention and > ongoing engineering commitment around it than the Oracle variant. To clarify: "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1] whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports. David [1] http://openjdk.java.net/projects/aarch32-port/ > Before making a choice of one AArch32 port vs the other (if such a choice > even needs to be made), I would like to hear more about the resources being > committed towards maintaining each, keeping each up to date, testing them on > various platforms (e.g. including building, testing, and supporting the popular > softfloat ABI variants imposed by some OS packages) and working on bug > fixes as needs appear. > ? Gil. > >> On Jun 4, 2018, at 6:24 PM, David Holmes wrote: >> >> Hi Bob, >> >> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. >> >> I think this is a good idea. >> >> Thanks, >> David >> >> On 5/06/2018 6:34 AM, Bob Vandette wrote: >>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >>> ARM ports and contributed them to OpenJDK. These ports have been used for >>> years in the embedded and mobile market, making them very stable and >>> having the benefit of a single source base which can produce both 32 and >>> 64-bit binaries. The downside of this contribution is that it resulted >>> in two 64-bit ARM implementations being available in OpenJDK. >>> I'd like to propose that we eliminate one of the 64-bit ARM ports and >>> encourage everyone to enhance and support the remaining 32 and 64 bit >>> ARM ports. This would avoid the creation of yet another port for these chip >>> architectures. The reduction of competing ports will allow everyone >>> to focus their attention on a single 64-bit port rather than diluting >>> our efforts. This will result in a higher quality and a more performant >>> implementation. >>> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >>> have done a great job of enhancing and keeping the AArch64 port up to >>> date with current and new Hotspot features. As a result, I propose that >>> we standardize the 64-bit ARM implementation on this port. >>> If there are no objections, I will file a JEP to remove the 64-bit ARM >>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >>> along with any build logic. This will leave the Oracle contributed >>> 32-bit ARM port and the AArch64 64-bit ARM port. >>> Let me know what you all think, >>> Bob Vandette > From magnus.ihse.bursie at oracle.com Thu Jun 7 09:41:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Jun 2018 11:41:41 +0200 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: From a build perspective, it would certainly simplify things if we have just a single port, so I'm in favour of this proposal. /Magnus On 2018-06-05 06:24, David Holmes wrote: > Hi Bob, > > Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. > > I think this is a good idea. > > Thanks, > David > > On 5/06/2018 6:34 AM, Bob Vandette wrote: >> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >> ARM ports and contributed them to OpenJDK.? These ports have been >> used for >> years in the embedded and mobile market, making them very stable and >> having the benefit of a single source base which can produce both 32 and >> 64-bit binaries.? The downside of this contribution is that it resulted >> in two 64-bit ARM implementations being available in OpenJDK. >> >> I'd like to propose that we eliminate one of the 64-bit ARM ports and >> encourage everyone to enhance and support the remaining 32 and 64 bit >> ARM ports. This would avoid the creation of yet another port for >> these chip >> architectures.? The reduction of competing ports will allow everyone >> to focus their attention on a single 64-bit port rather than diluting >> our efforts.? This will result in a higher quality and a more performant >> implementation. >> >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features.? As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic.? This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. >> >> Let me know what you all think, >> Bob Vandette >> >> From stuart.monteith at linaro.org Thu Jun 7 10:17:17 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 7 Jun 2018 11:17:17 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: <6c082b58-d3e3-68f9-ce50-7be4ed330a44@redhat.com> References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> <6c082b58-d3e3-68f9-ce50-7be4ed330a44@redhat.com> Message-ID: These failures appear related to user: goetz date: Mon May 07 09:11:21 2018 +0200 summary: 8201593: Print array length in ArrayIndexOutOfBoundsException. Reverting that patch (and 8202745: Remove hyphens from "out-of-bounds", and summary: 8203881: Print erroneous size in NegativeArraySizeException) and the tests pass. I've retested with them removed, and the tests run to completion. It appears my suggestion for using r22/r23 instead of the scratch registers weren't quite sufficient to be error free. BR, Stuart On 6 June 2018 at 12:39, Andrew Haley wrote: > On 06/06/2018 11:18 AM, Stuart Monteith wrote: >> Hi, >> The builds are failing with some simple jtreg failures - and not >> issues with ZGC as I first thought. >> >> The results are here:> http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/149/summary.html > > > The requested URL /jdkX/openjdk-jtreg-nightly-tests/builds/client-release/2018/149/JTwork-hotspot/scratch/3/hs_err_pid11249.log was not found on this server. > >> >> I spent a little time reproducing the results on a recent build - >> today and yesterday. Disabling/Enabling "UseBarriersForVolatile" makes >> no difference. >> I am testing with fastdebug and on the C1 compiler. These failures >> don't appear with C2. >> >> BR, >> Stuart >> >> On 5 June 2018 at 17:37, Andrew Haley wrote: >>> On 06/05/2018 05:25 PM, Roman Kennke wrote: >>>> Is anybody working on this? It blocks my testing on other unrelated >>>> patches and generally makes CI unhappy on aarch64. >>> >>> I'm waiting for Andrew Dinn to return. It's his code that was >>> broken by the modular GC barriers change. >>> >>> In the meantime you can set UseBarriersForVolatile to true. >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > -- > 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 Thu Jun 7 11:22:25 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2018 12:22:25 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> <6c082b58-d3e3-68f9-ce50-7be4ed330a44@redhat.com> Message-ID: <39c167e4-e6c6-961a-a520-98dfcf25f61e@redhat.com> On 06/07/2018 11:17 AM, Stuart Monteith wrote: > I've retested with them removed, and the tests run to completion. It > appears my suggestion for using r22/r23 instead of the scratch > registers weren't quite sufficient to be error free. That's right: everything is live. This is a very tough nut to crack, but I think this will do it: diff -r b06f330492cd src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Wed Jun 06 13:06:21 2018 +0100 +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Jun 07 12:15:42 2018 +0100 @@ -73,19 +73,20 @@ } if (_index->is_cpu_register()) { - __ mov(r22, _index->as_register()); + __ mov(rscratch1, _index->as_register()); } else { - __ mov(r22, _index->as_jint()); + __ mov(rscratch1, _index->as_jint()); } Runtime1::StubID stub_id; if (_throw_index_out_of_bounds_exception) { stub_id = Runtime1::throw_index_exception_id; } else { assert(_array != NULL, "sanity"); - __ mov(r23, _array->as_pointer_register()); + __ mov(rscratch2, _array->as_pointer_register()); stub_id = Runtime1::throw_range_check_failed_id; } - __ far_call(RuntimeAddress(Runtime1::entry_for(stub_id)), NULL, rscratch2); + __ lea(lr, RuntimeAddress(Runtime1::entry_for(stub_id))); + __ blr(lr); ce->add_call_info_here(_info); ce->verify_oop_map(_info); debug_only(__ should_not_reach_here()); diff -r b06f330492cd src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp --- a/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Wed Jun 06 13:06:21 2018 +0100 +++ b/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Thu Jun 07 12:15:42 2018 +0100 @@ -323,7 +323,7 @@ // target: the entry point of the method that creates and posts the exception oop -// has_argument: true if the exception needs arguments (passed in r22 and r23) +// has_argument: true if the exception needs arguments (passed in rscratch1 and rscratch2) OopMapSet* Runtime1::generate_exception_throw(StubAssembler* sasm, address target, bool has_argument) { // make a frame and preserve the caller's caller-save registers @@ -332,7 +332,9 @@ if (!has_argument) { call_offset = __ call_RT(noreg, noreg, target); } else { - call_offset = __ call_RT(noreg, noreg, target, r22, r23); + __ mov(c_rarg1, rscratch1); + __ mov(c_rarg2, rscratch2); + call_offset = __ call_RT(noreg, noreg, target); } OopMapSet* oop_maps = new OopMapSet(); oop_maps->add_gc_map(call_offset, oop_map); An alternative would be to push the array and the index onto the stack and then write a custom version of save_live_registers() which saves everything and pops the array and the index into r1 and r2, leaving exactly the same stack layout. That's more work, though, and not obviously any better. -- 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 Thu Jun 7 11:32:01 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2018 12:32:01 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: On 06/06/2018 07:33 PM, Dmitrij Pochepko wrote: > large test cycle passed. no new failures(although lots of JDK-8204331 > failures). As John Rose put it, we should clean up as we go. Try this. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- A non-text attachment was scrubbed... Name: vect_asm.diff Type: text/x-patch Size: 8218 bytes Desc: not available URL: From bob.vandette at oracle.com Thu Jun 7 14:48:16 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 7 Jun 2018 10:48:16 -0400 Subject: [aarch64-port-dev ] ARM port consolidation In-Reply-To: <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> Message-ID: <794BFAA0-6FCB-4730-9A89-B6B3F3D728BF@oracle.com> I agree with David. I do know that our implementation does run in AArch32 mode and it should be very easy to add dynamic AArch32 detection in order to make use of the few new AArch32 specific instructions such as the memory barrier instructions (LDAR/STLR). Since our current port already contains ARMv8 instruction pneumonics, we are already 1/2 way there. Bob. > On Jun 7, 2018, at 12:56 AM, David Holmes wrote: > > Hi Gil, > > On 7/06/2018 2:23 PM, Gil Tene wrote: >> This makes sense to me on the Aarch64 side. >> However, on the ARM32 side, I don't think the situation is as straightforward as >> what is being presented below, and I think more discussion and exploration of >> alternatives is needed. >> Much like with AArch64, there is an existing, active, community-developed and >> community-supported AArch32 port in OpenJDK that predates Oracle's open >> sourcing of their ARM32 version. That port is being used by multiple downstream >> builds and, at least for the past year+, it seems to have had more attention and >> ongoing engineering commitment around it than the Oracle variant. > > To clarify: > > "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1] > > whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports. > > David > > [1] http://openjdk.java.net/projects/aarch32-port/ > >> Before making a choice of one AArch32 port vs the other (if such a choice >> even needs to be made), I would like to hear more about the resources being >> committed towards maintaining each, keeping each up to date, testing them on >> various platforms (e.g. including building, testing, and supporting the popular >> softfloat ABI variants imposed by some OS packages) and working on bug >> fixes as needs appear. >> ? Gil. >>> On Jun 4, 2018, at 6:24 PM, David Holmes wrote: >>> >>> Hi Bob, >>> >>> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. >>> >>> I think this is a good idea. >>> >>> Thanks, >>> David >>> >>> On 5/06/2018 6:34 AM, Bob Vandette wrote: >>>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >>>> ARM ports and contributed them to OpenJDK. These ports have been used for >>>> years in the embedded and mobile market, making them very stable and >>>> having the benefit of a single source base which can produce both 32 and >>>> 64-bit binaries. The downside of this contribution is that it resulted >>>> in two 64-bit ARM implementations being available in OpenJDK. >>>> I'd like to propose that we eliminate one of the 64-bit ARM ports and >>>> encourage everyone to enhance and support the remaining 32 and 64 bit >>>> ARM ports. This would avoid the creation of yet another port for these chip >>>> architectures. The reduction of competing ports will allow everyone >>>> to focus their attention on a single 64-bit port rather than diluting >>>> our efforts. This will result in a higher quality and a more performant >>>> implementation. >>>> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >>>> have done a great job of enhancing and keeping the AArch64 port up to >>>> date with current and new Hotspot features. As a result, I propose that >>>> we standardize the 64-bit ARM implementation on this port. >>>> If there are no objections, I will file a JEP to remove the 64-bit ARM >>>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >>>> along with any build logic. This will leave the Oracle contributed >>>> 32-bit ARM port and the AArch64 64-bit ARM port. >>>> Let me know what you all think, >>>> Bob Vandette From stuart.monteith at linaro.org Thu Jun 7 15:29:57 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 7 Jun 2018 16:29:57 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: <39c167e4-e6c6-961a-a520-98dfcf25f61e@redhat.com> References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> <6c082b58-d3e3-68f9-ce50-7be4ed330a44@redhat.com> <39c167e4-e6c6-961a-a520-98dfcf25f61e@redhat.com> Message-ID: Hello, I think I prefer what you have there Andrew, rather than pushing onto the stack. I guess the mistake was when using r22 and r23 was our not saving them as callee-saved registers. There is nothing on the path from RangeCheckStub to the exception throw that overwrote r22 or r23 (AFAICT from stepping through the code), and the code does return. r8 and r9 have no opportunities to be overwritten between them being set and used, so it'll be ok. Shall I raise a bug and suggest your change be merged? BR, Stuart On 7 June 2018 at 12:22, Andrew Haley wrote: > On 06/07/2018 11:17 AM, Stuart Monteith wrote: >> I've retested with them removed, and the tests run to completion. It >> appears my suggestion for using r22/r23 instead of the scratch >> registers weren't quite sufficient to be error free. > > That's right: everything is live. This is a very tough nut to crack, but > I think this will do it: > > diff -r b06f330492cd src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Wed Jun 06 13:06:21 2018 +0100 > +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp Thu Jun 07 12:15:42 2018 +0100 > @@ -73,19 +73,20 @@ > } > > if (_index->is_cpu_register()) { > - __ mov(r22, _index->as_register()); > + __ mov(rscratch1, _index->as_register()); > } else { > - __ mov(r22, _index->as_jint()); > + __ mov(rscratch1, _index->as_jint()); > } > Runtime1::StubID stub_id; > if (_throw_index_out_of_bounds_exception) { > stub_id = Runtime1::throw_index_exception_id; > } else { > assert(_array != NULL, "sanity"); > - __ mov(r23, _array->as_pointer_register()); > + __ mov(rscratch2, _array->as_pointer_register()); > stub_id = Runtime1::throw_range_check_failed_id; > } > - __ far_call(RuntimeAddress(Runtime1::entry_for(stub_id)), NULL, rscratch2); > + __ lea(lr, RuntimeAddress(Runtime1::entry_for(stub_id))); > + __ blr(lr); > ce->add_call_info_here(_info); > ce->verify_oop_map(_info); > debug_only(__ should_not_reach_here()); > diff -r b06f330492cd src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Wed Jun 06 13:06:21 2018 +0100 > +++ b/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp Thu Jun 07 12:15:42 2018 +0100 > @@ -323,7 +323,7 @@ > > > // target: the entry point of the method that creates and posts the exception oop > -// has_argument: true if the exception needs arguments (passed in r22 and r23) > +// has_argument: true if the exception needs arguments (passed in rscratch1 and rscratch2) > > OopMapSet* Runtime1::generate_exception_throw(StubAssembler* sasm, address target, bool has_argument) { > // make a frame and preserve the caller's caller-save registers > @@ -332,7 +332,9 @@ > if (!has_argument) { > call_offset = __ call_RT(noreg, noreg, target); > } else { > - call_offset = __ call_RT(noreg, noreg, target, r22, r23); > + __ mov(c_rarg1, rscratch1); > + __ mov(c_rarg2, rscratch2); > + call_offset = __ call_RT(noreg, noreg, target); > } > OopMapSet* oop_maps = new OopMapSet(); > oop_maps->add_gc_map(call_offset, oop_map); > > An alternative would be to push the array and the index onto the stack > and then write a custom version of save_live_registers() which saves > everything and pops the array and the index into r1 and r2, leaving > exactly the same stack layout. That's more work, though, and not > obviously any better. > > -- > 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 Thu Jun 7 17:17:24 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jun 2018 18:17:24 +0100 Subject: [aarch64-port-dev ] Assert failure building Graal In-Reply-To: References: <8f31c4a1-6f49-31c9-1900-62818be7e3f0@redhat.com> <6702633f-1b79-bb1b-7825-d12fbd6b3fc9@redhat.com> <60153add-21fa-102e-44fa-9a5c61efa637@redhat.com> <6c082b58-d3e3-68f9-ce50-7be4ed330a44@redhat.com> <39c167e4-e6c6-961a-a520-98dfcf25f61e@redhat.com> Message-ID: On 06/07/2018 04:29 PM, Stuart Monteith wrote: > I think I prefer what you have there Andrew, rather than pushing > onto the stack. I guess the mistake was when using r22 and r23 was our > not saving them as callee-saved registers. There is nothing on the > path from RangeCheckStub to the exception throw that overwrote r22 or > r23 (AFAICT from stepping through the code), and the code does return. That's right. The important code path is something like this: static volatile Object o; static void count(int n, int[] a) { try { poo += a[n/10_000_000]; } catch (Exception e) { o = a; throw e; } } Here, when we hit the throw_range_check_failed Runtime1 stub everything is live. We call into the runtime with everything on the stack, and the runtime returns to that same stack. Then from the stub we jump to another stub, forward_exception Runtime1. That searches for a handler for the exception, finds it in the compiled code for count(), then restores all of our registers and jumps to it. It's essential that all of the registers, integer and vector, are restored at this point. > r8 and r9 have no opportunities to be overwritten between them being > set and used, so it'll be ok. Yes. It's a bit too hairy for my taste but it'll work. > Shall I raise a bug and suggest your change be merged? I think so. -- 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 Fri Jun 8 22:06:45 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 8 Jun 2018 23:06:45 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at Message-ID: Hello, Please review a patch for "8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at". Currently you won't be able to build aarch64 debug builds because of assertions tripping in load_at. JDK-8203353 refined the decorators somewhat, which worked fine on x86, but not aarch64. In this patch, I change the code to match x86's in that access_load_at is called instead of load_at, which means that AccessInternal::decorator_fixup is called, which fixes the expectations of the assertions in load_at and other places. The accesses of load_at and access_load_at (and store equivalents) now match x86. CR: https://bugs.openjdk.java.net/browse/JDK-8204628 webrev: http://cr.openjdk.java.net/~smonteith/8204628/webrev/ The assertions no longer trip when tested with C1 or C2. Many thanks, Stuart From Derek.White at cavium.com Fri Jun 8 22:22:46 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 8 Jun 2018 22:22:46 +0000 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: Hi Stuart, Can you lose the declaration of BarrierSetAssembler bs at line 2116? This looks good otherwise. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Stuart Monteith > Sent: Friday, June 08, 2018 6:07 PM > To: aarch64-port-dev ; hotspot-dev > Source Developers ; Erik Osterlund > > Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in > BarrierSetAssembler::load_at > > Hello, > Please review a patch for "8204628 [AArch64] Assertion failure in > BarrierSetAssembler::load_at". > > Currently you won't be able to build aarch64 debug builds because of > assertions tripping in load_at. > JDK-8203353 refined the decorators somewhat, which worked fine on x86, > but not aarch64. > > In this patch, I change the code to match x86's in that access_load_at is > called instead of load_at, which means that AccessInternal::decorator_fixup > is called, which fixes the expectations of the assertions in load_at and other > places. The accesses of load_at and access_load_at (and store equivalents) > now match x86. > > CR: https://bugs.openjdk.java.net/browse/JDK-8204628 > > webrev: http://cr.openjdk.java.net/~smonteith/8204628/webrev/ > > The assertions no longer trip when tested with C1 or C2. > > Many thanks, > Stuart From ci_notify at linaro.org Sat Jun 9 00:04:06 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 9 Jun 2018 00:04:06 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <84237135.1029.1528502646720.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/158/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/15 pass: 1,674; fail: 14; error: 2; not run: 11,615 Build 1: aarch64/2018/apr/17 pass: 1,675; fail: 14; error: 1; not run: 11,615 Build 2: aarch64/2018/may/10 pass: 3,190; fail: 14; error: 3; not run: 11,616 Build 3: aarch64/2018/may/11 pass: 3,192; fail: 12; error: 3; not run: 11,616 Build 4: aarch64/2018/may/13 pass: 3,191; fail: 13; error: 3; not run: 11,616 Build 5: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 6: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 7: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 8: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 9: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 10: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 11: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 12: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 13: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/15 pass: 7,824; fail: 583; error: 29 Build 1: aarch64/2018/apr/17 pass: 7,800; fail: 621; error: 15 Build 2: aarch64/2018/may/10 pass: 7,905; fail: 595; error: 22 Build 3: aarch64/2018/may/11 pass: 7,880; fail: 623; error: 19 Build 4: aarch64/2018/may/13 pass: 7,903; fail: 599; error: 23 Build 5: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 6: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 7: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 8: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 9: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 10: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 11: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 12: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 13: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 14: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/15 pass: 3,855; fail: 6; error: 3 Build 1: aarch64/2018/apr/17 pass: 3,856; fail: 6; error: 2 Build 2: aarch64/2018/may/10 pass: 3,865; fail: 6 Build 3: aarch64/2018/may/11 pass: 3,865; fail: 6 Build 4: aarch64/2018/may/13 pass: 3,862; fail: 6; error: 4 Build 5: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 6: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 7: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 8: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 9: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 10: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 11: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 12: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 13: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 14: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/15 pass: 1,682; fail: 13; error: 2; not run: 11,615 Build 1: aarch64/2018/apr/17 pass: 1,682; fail: 14; error: 1; not run: 11,615 Build 2: aarch64/2018/may/10 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 3: aarch64/2018/may/11 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 4: aarch64/2018/may/13 pass: 3,200; fail: 11; error: 3; not run: 11,616 Build 5: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 6: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 7: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 8: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 9: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 10: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 11: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/15 pass: 7,849; fail: 560; error: 27 Build 1: aarch64/2018/apr/17 pass: 7,825; fail: 593; error: 18 Build 2: aarch64/2018/may/10 pass: 7,918; fail: 586; error: 18 Build 3: aarch64/2018/may/11 pass: 7,912; fail: 592; error: 18 Build 4: aarch64/2018/may/13 pass: 7,892; fail: 616; error: 17 Build 5: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 6: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 7: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 8: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 9: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 10: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 11: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 12: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 13: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 14: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/15 pass: 3,854; fail: 6; error: 4 Build 1: aarch64/2018/apr/17 pass: 3,854; fail: 6; error: 4 Build 2: aarch64/2018/may/10 pass: 3,862; fail: 6; error: 3 Build 3: aarch64/2018/may/11 pass: 3,860; fail: 6; error: 5 Build 4: aarch64/2018/may/13 pass: 3,861; fail: 6; error: 5 Build 5: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 6: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 7: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 8: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 9: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 10: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 11: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 12: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 13: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 14: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 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): 0.62x Relative performance: Server critical-jOPS (nc): 0.54x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 65.65, Server: 111.14 Client 65.65 / Client 2014-04-01 (43.00): 1.53x Server 111.14 / Server 2014-04-01 (71.00): 1.57x 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 15 days. 2018-04-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/105/results/ 2018-04-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/107/results/ 2018-05-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/130/results/ 2018-05-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/131/results/ 2018-05-14 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/133/results/ 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From erik.osterlund at oracle.com Sat Jun 9 06:47:29 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Sat, 9 Jun 2018 08:47:29 +0200 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: <2F2292FF-8DF8-4082-B1A1-804190993F7B@oracle.com> Hi Stuart, Looks good. Thanks, /Erik > On 9 Jun 2018, at 00:06, Stuart Monteith wrote: > > Hello, > Please review a patch for "8204628 [AArch64] Assertion failure in > BarrierSetAssembler::load_at". > > Currently you won't be able to build aarch64 debug builds because of > assertions tripping in load_at. > JDK-8203353 refined the decorators somewhat, which worked fine on x86, > but not aarch64. > > In this patch, I change the code to match x86's in that access_load_at > is called instead of load_at, which means that > AccessInternal::decorator_fixup is called, which fixes the > expectations of the assertions in load_at and other places. The > accesses of load_at and access_load_at (and store equivalents) now > match x86. > > CR: https://bugs.openjdk.java.net/browse/JDK-8204628 > > webrev: http://cr.openjdk.java.net/~smonteith/8204628/webrev/ > > The assertions no longer trip when tested with C1 or C2. > > Many thanks, > Stuart From aph at redhat.com Sat Jun 9 08:38:23 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 9 Jun 2018 09:38:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: Hi, On 06/08/2018 11:06 PM, Stuart Monteith wrote: > Please review a patch for "8204628 [AArch64] Assertion failure in > BarrierSetAssembler::load_at". > > Currently you won't be able to build aarch64 debug builds because of > assertions tripping in load_at. > JDK-8203353 refined the decorators somewhat, which worked fine on x86, > but not aarch64. > > In this patch, I change the code to match x86's in that access_load_at > is called instead of load_at, which means that > AccessInternal::decorator_fixup is called, which fixes the > expectations of the assertions in load_at and other places. The > accesses of load_at and access_load_at (and store equivalents) now > match x86. > > CR: https://bugs.openjdk.java.net/browse/JDK-8204628 > > webrev: http://cr.openjdk.java.net/~smonteith/8204628/webrev/ > > The assertions no longer trip when tested with C1 or C2. Fine by me too. The declaration of BarrierSetAssembler *bs is unused. -- 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 Sun Jun 10 16:54:47 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 10 Jun 2018 19:54:47 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: Hello Everybody, Please, review updated webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 CR link: https://bugs.openjdk.java.net/browse/JDK-8203481 -Dmitry On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: > Hello Everybody, > > Please review small fix > > http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8203481 > > Testing: > > jfr tests that depends to safe_for_sender functionality > > ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java > ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java > > fails on AARCH64. > > These tests passed after the fix. > > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From stuart.monteith at linaro.org Sun Jun 10 20:42:33 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Sun, 10 Jun 2018 21:42:33 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: Thanks everyone, There is a new patch here: http://cr.openjdk.java.net/~smonteith/8204628/webrev.1/ Could someone sponsor this please? Thanks, Stuart On 9 June 2018 at 09:38, Andrew Haley wrote: > Hi, > > On 06/08/2018 11:06 PM, Stuart Monteith wrote: > >> Please review a patch for "8204628 [AArch64] Assertion failure in >> BarrierSetAssembler::load_at". >> >> Currently you won't be able to build aarch64 debug builds because of >> assertions tripping in load_at. >> JDK-8203353 refined the decorators somewhat, which worked fine on x86, >> but not aarch64. >> >> In this patch, I change the code to match x86's in that access_load_at >> is called instead of load_at, which means that >> AccessInternal::decorator_fixup is called, which fixes the >> expectations of the assertions in load_at and other places. The >> accesses of load_at and access_load_at (and store equivalents) now >> match x86. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8204628 >> >> webrev: http://cr.openjdk.java.net/~smonteith/8204628/webrev/ >> >> The assertions no longer trip when tested with C1 or C2. > > Fine by me too. The declaration of BarrierSetAssembler *bs is unused. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Sun Jun 10 21:05:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jun 2018 07:05:59 +1000 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: Hi Dmitry, I have to admit I still can't connect all the pieces here. When we are operating in frame::safe_for_sender, what has set _unextended_sp? Can you walk through a complete example? I can't quite connect Andrew's example to the original problem. It still seems to me that the current frame should have: sp <= unextended_sp <= stack_base() ?? Thanks, David On 11/06/2018 2:54 AM, Dmitry Samersoff wrote: > Hello Everybody, > > Please, review updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 > > CR link: > > https://bugs.openjdk.java.net/browse/JDK-8203481 > > -Dmitry > > On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> Please review small fix >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >> >> CR: >> >> https://bugs.openjdk.java.net/browse/JDK-8203481 >> >> Testing: >> >> jfr tests that depends to safe_for_sender functionality >> >> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >> >> fails on AARCH64. >> >> These tests passed after the fix. >> >> > > From ci_notify at linaro.org Sun Jun 10 23:28:38 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 10 Jun 2018 23:28:38 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <110626943.1130.1528673318580.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/160/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/17 pass: 1,675; fail: 14; error: 1; not run: 11,615 Build 1: aarch64/2018/may/10 pass: 3,190; fail: 14; error: 3; not run: 11,616 Build 2: aarch64/2018/may/11 pass: 3,192; fail: 12; error: 3; not run: 11,616 Build 3: aarch64/2018/may/13 pass: 3,191; fail: 13; error: 3; not run: 11,616 Build 4: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 5: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 6: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 7: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 8: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 9: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 10: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 11: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 12: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 14: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/17 pass: 7,800; fail: 621; error: 15 Build 1: aarch64/2018/may/10 pass: 7,905; fail: 595; error: 22 Build 2: aarch64/2018/may/11 pass: 7,880; fail: 623; error: 19 Build 3: aarch64/2018/may/13 pass: 7,903; fail: 599; error: 23 Build 4: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 5: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 6: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 7: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 8: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 9: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 10: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 11: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 12: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 13: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 14: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/17 pass: 3,856; fail: 6; error: 2 Build 1: aarch64/2018/may/10 pass: 3,865; fail: 6 Build 2: aarch64/2018/may/11 pass: 3,865; fail: 6 Build 3: aarch64/2018/may/13 pass: 3,862; fail: 6; error: 4 Build 4: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 5: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 6: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 7: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 8: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 9: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 10: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 11: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 12: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 13: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 14: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/17 pass: 1,682; fail: 14; error: 1; not run: 11,615 Build 1: aarch64/2018/may/10 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 2: aarch64/2018/may/11 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 3: aarch64/2018/may/13 pass: 3,200; fail: 11; error: 3; not run: 11,616 Build 4: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 5: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 6: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 7: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 8: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 9: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 10: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/17 pass: 7,825; fail: 593; error: 18 Build 1: aarch64/2018/may/10 pass: 7,918; fail: 586; error: 18 Build 2: aarch64/2018/may/11 pass: 7,912; fail: 592; error: 18 Build 3: aarch64/2018/may/13 pass: 7,892; fail: 616; error: 17 Build 4: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 5: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 6: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 7: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 8: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 9: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 10: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 11: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 12: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 13: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 14: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/apr/17 pass: 3,854; fail: 6; error: 4 Build 1: aarch64/2018/may/10 pass: 3,862; fail: 6; error: 3 Build 2: aarch64/2018/may/11 pass: 3,860; fail: 6; error: 5 Build 3: aarch64/2018/may/13 pass: 3,861; fail: 6; error: 5 Build 4: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 5: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 6: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 7: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 8: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 9: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 10: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 11: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 12: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 13: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 14: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 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): 0.62x Relative performance: Server critical-jOPS (nc): 0.55x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.27, Server: 109.42 Client 66.27 / Client 2014-04-01 (43.00): 1.54x Server 109.42 / Server 2014-04-01 (71.00): 1.54x 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 15 days. 2018-04-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/107/results/ 2018-05-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/130/results/ 2018-05-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/131/results/ 2018-05-14 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/133/results/ 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From gnu.andrew at redhat.com Mon Jun 11 04:06:46 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jun 2018 05:06:46 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> Message-ID: On 15 May 2018 at 15:50, Roman Kennke wrote: > This integrates latest Shenandoah changes from shenandoah/jdk8u > repository. It includes all Shenandoah changes since Oct 2017. It's all > backports from sh/jdk -> sh/jdk10 -> sh/jdk9 -> sh/jdk8u or jdk8u > specific bugfixes. It's all been reviewed, baked and > thoroughly tested upstream. > > The integration brings lots of major and minor improvements, bugfixes > and tests. > > The list of changesets to be pushed is this: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-05-15/jdk8u-shenandoah-integration-2018-05-15.txt > > The complete webrev is: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-05-15/webrev.00/ > > It builds release+fastdebug, and passes all hotspot_gc_shenandoah tests. > > I'll tag the forest with: > > aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-05-15 > > In retrospect, I'm thinking I should have at least found time to review the list of changes, if not the Shenandoah code. In working with this, I've run across changes like this: changeset: 10408:908723b9f760 user: sangheki date: Thu Feb 09 19:08:32 2017 -0800 summary: Cherry-pick JDK-8173013: JVMTI tagged object access needs G1 pre-barrier changeset: 10409:388a0e0523c2 user: mdoerr date: Tue Sep 06 13:01:27 2016 +0200 summary: Cherry-pick JDK-8165489: Missing G1 barrier in Unsafe_GetObjectVolatile changeset: 10410:ea3ab1a51237 user: shade date: Wed Feb 07 21:53:38 2018 +0000 summary: Cherry-pick JDK-8187577: JVM crash during gc doing concurrent marking We shouldn't be backporting upstream changes into just Shenandoah. These should go first to jdk8u/jdk8u, and then, if we need them before they make an upstream 8u release, they should go to aarch64/jdk8u. Having them coming in via Shenandoah means we're creating differences between aarch64/jdk8u and aarch64/shenandoah-jdk8u which aren't Shenandoah-specific. Please let's not do that. 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 shade at redhat.com Mon Jun 11 07:22:55 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Jun 2018 09:22:55 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> Message-ID: On 06/11/2018 06:06 AM, Andrew Hughes wrote: > In working with this, I've run across changes like this: These things are upstream jdk8u/jdk8u: > changeset: 10408:908723b9f760 > user: sangheki > date: Thu Feb 09 19:08:32 2017 -0800 > summary: Cherry-pick JDK-8173013: JVMTI tagged object access needs > G1 pre-barrier https://bugs.openjdk.java.net/browse/JDK-8201583 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/767e8338f749 > changeset: 10409:388a0e0523c2 > user: mdoerr > date: Tue Sep 06 13:01:27 2016 +0200 > summary: Cherry-pick JDK-8165489: Missing G1 barrier in > Unsafe_GetObjectVolatile https://bugs.openjdk.java.net/browse/JDK-8202916 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/576949777967 > changeset: 10410:ea3ab1a51237 > user: shade > date: Wed Feb 07 21:53:38 2018 +0000 > summary: Cherry-pick JDK-8187577: JVM crash during gc doing > concurrent marking https://bugs.openjdk.java.net/browse/JDK-8187577 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/da2bb5e60234 > We shouldn't be backporting upstream changes into just Shenandoah. These should go first to > jdk8u/jdk8u, and then, if we need them before they make an upstream 8u release, they should go to > aarch64/jdk8u. So your concern here is that we need to get those into aarch64/jdk8u first? We can do that. I thought it would happen automatically with jdk8u pickup. -Aleksey From stuart.monteith at linaro.org Mon Jun 11 12:49:12 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 11 Jun 2018 13:49:12 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage Message-ID: Hello, Here is Andrew's patch to correct a poor choice of registers in JDK-8201593. http://cr.openjdk.java.net/~smonteith/8204606/webrev/ CR: https://bugs.openjdk.java.net/browse/JDK-8204606 Retested with C1 on tier1 tests. Thanks, Stuart From adinn at redhat.com Tue Jun 12 09:02:29 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 Jun 2018 10:02:29 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: References: Message-ID: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> On 11/06/18 13:49, Stuart Monteith wrote: > Here is Andrew's patch to correct a poor choice of registers in JDK-8201593. > > http://cr.openjdk.java.net/~smonteith/8204606/webrev/ > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8204606 > > Retested with C1 on tier1 tests. Yes, that looks good. Thanks. 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 adinn at redhat.com Tue Jun 12 09:04:43 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 Jun 2018 10:04:43 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: <08d9a9a9-4ee6-c77a-c44a-34c6601d9211@redhat.com> On 10/06/18 21:42, Stuart Monteith wrote: > Thanks everyone, > There is a new patch here: > http://cr.openjdk.java.net/~smonteith/8204628/webrev.1/ > > Could someone sponsor this please? That looks fine. I will push it for you. 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 stuart.monteith at linaro.org Tue Jun 12 09:09:43 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 12 Jun 2018 10:09:43 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> References: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> Message-ID: Thanks Andrew. Shall I push a nice patch with "reviewed-by", etc? It should include "Contributed-by: aph at redhat.com" On 12 June 2018 at 10:02, Andrew Dinn wrote: > On 11/06/18 13:49, Stuart Monteith wrote: >> Here is Andrew's patch to correct a poor choice of registers in JDK-8201593. >> >> http://cr.openjdk.java.net/~smonteith/8204606/webrev/ >> >> CR: >> >> https://bugs.openjdk.java.net/browse/JDK-8204606 >> >> Retested with C1 on tier1 tests. > Yes, that looks good. Thanks. > > 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 adinn at redhat.com Tue Jun 12 09:18:04 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 Jun 2018 10:18:04 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: References: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> Message-ID: <16c36afe-bfcd-5825-8210-12d36480e831@redhat.com> On 12/06/18 10:09, Stuart Monteith wrote: > Shall I push a nice patch with "reviewed-by", etc? It should include > "Contributed-by: aph at redhat.com" I'll commit the patch from the webrev with Andrew Haley as the patch author and the two of us as reviewers -- you did the testing so that counts as an unofficial review and we don't need a second official reviewer since this is AArch64-specific. I think that would be more appropriate than adding a contributed-by for Andrew. 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 stuart.monteith at linaro.org Tue Jun 12 09:20:22 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 12 Jun 2018 10:20:22 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204628 [AArch64] Assertion failure in BarrierSetAssembler::load_at In-Reply-To: <08d9a9a9-4ee6-c77a-c44a-34c6601d9211@redhat.com> References: <08d9a9a9-4ee6-c77a-c44a-34c6601d9211@redhat.com> Message-ID: Thanks Andrew. We'll then be able to build debug builds. Frankly, I'm tempted to switch my builds to building with fastdebug. It's not good for the benchmarking results, but I'd rather fail fast. BR, Stuart On 12 June 2018 at 10:04, Andrew Dinn wrote: > On 10/06/18 21:42, Stuart Monteith wrote: >> Thanks everyone, >> There is a new patch here: >> http://cr.openjdk.java.net/~smonteith/8204628/webrev.1/ >> >> Could someone sponsor this please? > That looks fine. I will push it for you. > > 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 stuart.monteith at linaro.org Tue Jun 12 09:23:30 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 12 Jun 2018 10:23:30 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204606 - [Aarch64] SIGSEGVs caused by C1 because of improper register usage In-Reply-To: <16c36afe-bfcd-5825-8210-12d36480e831@redhat.com> References: <50bc753c-ffbd-3a1a-e2dc-aca85d7db408@redhat.com> <16c36afe-bfcd-5825-8210-12d36480e831@redhat.com> Message-ID: That's even better, thanks. I assumed that mercurial wouldn't allow you to do what you suggested. On 12 June 2018 at 10:18, Andrew Dinn wrote: > On 12/06/18 10:09, Stuart Monteith wrote: >> Shall I push a nice patch with "reviewed-by", etc? It should include >> "Contributed-by: aph at redhat.com" > > I'll commit the patch from the webrev with Andrew Haley as the patch > author and the two of us as reviewers -- you did the testing so that > counts as an unofficial review and we don't need a second official > reviewer since this is AArch64-specific. > > I think that would be more appropriate than adding a contributed-by for > Andrew. > > 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 ci_notify at linaro.org Wed Jun 13 00:22:06 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 13 Jun 2018 00:22:06 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1254701631.1932.1528849326681.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/162/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/10 pass: 3,190; fail: 14; error: 3; not run: 11,616 Build 1: aarch64/2018/may/11 pass: 3,192; fail: 12; error: 3; not run: 11,616 Build 2: aarch64/2018/may/13 pass: 3,191; fail: 13; error: 3; not run: 11,616 Build 3: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 4: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 5: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 6: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 7: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 8: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 9: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 10: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 11: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 13: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/10 pass: 7,905; fail: 595; error: 22 Build 1: aarch64/2018/may/11 pass: 7,880; fail: 623; error: 19 Build 2: aarch64/2018/may/13 pass: 7,903; fail: 599; error: 23 Build 3: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 4: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 5: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 6: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 7: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 8: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 9: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 10: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 11: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 12: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 13: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 14: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/10 pass: 3,865; fail: 6 Build 1: aarch64/2018/may/11 pass: 3,865; fail: 6 Build 2: aarch64/2018/may/13 pass: 3,862; fail: 6; error: 4 Build 3: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 4: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 5: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 6: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 7: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 8: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 9: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 10: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 11: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 12: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 13: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 14: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/10 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 1: aarch64/2018/may/11 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 2: aarch64/2018/may/13 pass: 3,200; fail: 11; error: 3; not run: 11,616 Build 3: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 4: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 5: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 6: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 7: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 8: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 9: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/10 pass: 7,918; fail: 586; error: 18 Build 1: aarch64/2018/may/11 pass: 7,912; fail: 592; error: 18 Build 2: aarch64/2018/may/13 pass: 7,892; fail: 616; error: 17 Build 3: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 4: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 5: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 6: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 7: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 8: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 9: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 10: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 11: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 12: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 13: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 14: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/10 pass: 3,862; fail: 6; error: 3 Build 1: aarch64/2018/may/11 pass: 3,860; fail: 6; error: 5 Build 2: aarch64/2018/may/13 pass: 3,861; fail: 6; error: 5 Build 3: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 4: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 5: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 6: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 7: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 8: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 9: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 10: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 11: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 12: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 13: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 14: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 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): 0.63x Relative performance: Server critical-jOPS (nc): 0.57x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.27, Server: 109.42 Client 66.27 / Client 2014-04-01 (43.00): 1.54x Server 109.42 / Server 2014-04-01 (71.00): 1.54x 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 15 days. 2018-05-11 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/130/results/ 2018-05-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/131/results/ 2018-05-14 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/133/results/ 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From andrey.petushkov at gmail.com Wed Jun 13 12:40:38 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 15:40:38 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking Message-ID: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Dear Hotspot developers, It looks like the cause of the https://bugs.openjdk.java.net/browse/JDK-8153107 problem is that ObjectSynchronizer::quick_enter implementation leaves the BasicLock marked as recursive (DHW==0) in case that the lock is inflated and already taken. As such the routines which first check the recursive stack locking (e.g. fast_exit) consider this lock as non-inflated recursive and hence do not decrement _recursions field of ObjectMonitor, leaving the monitor locked forever. In contrary the slow path does work the right way: ObjectSynchronizer::slow_enter first marks stack lock as non-locked and non-recursive (DHW==3) and then delegates to ObjectMonitor::enter to increment _recursions. So from the source code prospective this bug looks like platform-independent, contrary to what?s was found under https://bugs.openjdk.java.net/browse/JDK-8131715 . Unfortunately I cannot prove it with an example. The only case it fails for me is runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on aarch32 openjdk port. The following changes fix the problem: diff --git a/src/hotspot/share/runtime/sharedRuntime.cpp b/src/hotspot/share/runtime/sharedRuntime.cpp --- a/src/hotspot/share/runtime/sharedRuntime.cpp +++ b/src/hotspot/share/runtime/sharedRuntime.cpp @@ -1985,9 +1985,7 @@ JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) // Disable ObjectSynchronizer::quick_enter() in default config // on AARCH64 and ARM until JDK-8153107 is resolved. - if (ARM_ONLY((SyncFlags & 256) != 0 &&) - AARCH64_ONLY((SyncFlags & 256) != 0 &&) - !SafepointSynchronize::is_synchronizing()) { + if (!SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint // so that the calling thread reaches the safepoint more quickly. if (ObjectSynchronizer::quick_enter(_obj, thread, lock)) return; diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp --- a/src/hotspot/share/runtime/synchronizer.cpp +++ b/src/hotspot/share/runtime/synchronizer.cpp @@ -220,11 +220,6 @@ // Case: light contention possibly amenable to TLE // Case: TLE inimical operations such as nested/recursive synchronization - if (owner == Self) { - m->_recursions++; - return true; - } - // This Java Monitor is inflated so obj's header will never be // displaced to this thread's BasicLock. Make the displaced header // non-NULL so this BasicLock is not seen as recursive nor as @@ -237,6 +232,11 @@ // and last are the inflated Java Monitor (ObjectMonitor) checks. lock->set_displaced_header(markOopDesc::unused_mark()); + if (owner == Self) { + m->_recursions++; + return true; + } + if (owner == NULL && Atomic::replace_if_null(Self, &(m->_owner))) { assert(m->_recursions == 0, "invariant"); assert(m->_owner == Self, "invariant"); Regards, Andrey From aph at redhat.com Wed Jun 13 13:37:54 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 14:37:54 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: On 06/13/2018 01:40 PM, Andrey Petushkov wrote: > It looks like the cause of the > https://bugs.openjdk.java.net/browse/JDK-8153107 > problem is that > ObjectSynchronizer::quick_enter implementation leaves the BasicLock > marked as recursive (DHW==0) in case that the lock is inflated and > already taken. As such the routines which first check the recursive > stack locking (e.g. fast_exit) consider this lock as non-inflated > recursive and hence do not decrement _recursions field of > ObjectMonitor, leaving the monitor locked forever. In contrary the > slow path does work the right way: ObjectSynchronizer::slow_enter > first marks stack lock as non-locked and non-recursive (DHW==3) and > then delegates to ObjectMonitor::enter to increment _recursions. > So from the source code prospective this bug looks like > platform-independent, contrary to what?s was found under > https://bugs.openjdk.java.net/browse/JDK-8131715 > . Unfortunately I > cannot prove it with an example. The only case it fails for me is > runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on > aarch32 openjdk port. The following changes fix the problem: Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 and ARM32 ports. This bug was never seen in the AARCH64 open port, so the workaround shouldn't be enabled for it. 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems Reviewed-by: dcubed diff -r afd6ae4fec81 -r 71d7ced6c439 hotspot/src/share/vm/runtime/sharedRuntime.cpp --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 11:53:20 2016 +0530 +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 10:44:17 2016 -0400 @@ -1983,8 +1983,10 @@ // Handles the uncommon case in locking, i.e., contention or an inflated lock. JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) // Disable ObjectSynchronizer::quick_enter() in default config - // on AARCH64 until JDK-8153107 is resolved. - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { + // on AARCH64 and ARM until JDK-8153107 is resolved. + if (ARM_ONLY((SyncFlags & 256) != 0 &&) + AARCH64_ONLY((SyncFlags & 256) != 0 &&) + !SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint Why did you move the code which handles recursive locking counts? Do you believe that it's incorrect where it is, and if so, why? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Wed Jun 13 14:00:26 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 17:00:26 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: > On 13 Jun 2018, at 16:37, Andrew Haley wrote: > > On 06/13/2018 01:40 PM, Andrey Petushkov wrote: > >> It looks like the cause of the >> https://bugs.openjdk.java.net/browse/JDK-8153107 >> problem is that >> ObjectSynchronizer::quick_enter implementation leaves the BasicLock >> marked as recursive (DHW==0) in case that the lock is inflated and >> already taken. As such the routines which first check the recursive >> stack locking (e.g. fast_exit) consider this lock as non-inflated >> recursive and hence do not decrement _recursions field of >> ObjectMonitor, leaving the monitor locked forever. In contrary the >> slow path does work the right way: ObjectSynchronizer::slow_enter >> first marks stack lock as non-locked and non-recursive (DHW==3) and >> then delegates to ObjectMonitor::enter to increment _recursions. > >> So from the source code prospective this bug looks like >> platform-independent, contrary to what?s was found under >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> . Unfortunately I >> cannot prove it with an example. The only case it fails for me is >> runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on >> aarch32 openjdk port. The following changes fix the problem: > > Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 > and ARM32 ports. This bug was never seen in the AARCH64 open port, > so the workaround shouldn't be enabled for it. > > 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems > Reviewed-by: dcubed > diff -r afd6ae4fec81 -r 71d7ced6c439 hotspot/src/share/vm/runtime/sharedRuntime.cpp > --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 11:53:20 2016 +0530 > +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 10:44:17 2016 -0400 > @@ -1983,8 +1983,10 @@ > // Handles the uncommon case in locking, i.e., contention or an inflated lock. > JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) > // Disable ObjectSynchronizer::quick_enter() in default config > - // on AARCH64 until JDK-8153107 is resolved. > - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { > + // on AARCH64 and ARM until JDK-8153107 is resolved. > + if (ARM_ONLY((SyncFlags & 256) != 0 &&) > + AARCH64_ONLY((SyncFlags & 256) != 0 &&) > + !SafepointSynchronize::is_synchronizing()) { > // Only try quick_enter() if we're not trying to reach a safepoint > > Why did you move the code which handles recursive locking counts? Do > you believe that it's incorrect where it is, and if so, why? That?s exactly what I?ve been trying to describe. The displaced header shall be assigned 3 when recursive locking happens on inflated lock. At least with the current design of the exit code which uses it as an indicator that inflated lock is present. So it seems to me that currently the number of recursive locks on an object is the count of relevant stack lock structures with mark(DHW)!=3 (i.e. first lock + any stack locks prior to inflation) + _recursions field value of the inflated lock structure. The sequence of operations under review was breaking this assumption: any recursion via quick_enter was increasing both number of stack locks with DHW==0 and value of _recursions. While the slow_enter only increased _recursions The above is idea I got from reading the code, I hope someone more experienced (@Daniel Daugherty?) can chime in and prove me right or wrong Andrey > > -- > 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 Wed Jun 13 15:02:43 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Jun 2018 16:02:43 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> Message-ID: On 11 June 2018 at 08:22, Aleksey Shipilev wrote: snip... > >> We shouldn't be backporting upstream changes into just Shenandoah. These should go first to >> jdk8u/jdk8u, and then, if we need them before they make an upstream 8u release, they should go to >> aarch64/jdk8u. > So your concern here is that we need to get those into aarch64/jdk8u first? My concern is that we're creating needless differences between aarch64/jdk8u and aarch64/jdk8u-shenandoah. > We can do that. I > thought it would happen automatically with jdk8u pickup. It will when we pull in whatever 8u version they are destined for. 8187577 is scheduled for the next CPU (8u181), the other two for the feature update 8u192 in October. Clearly though, you want them for Shenandoah earlier than that. In this case, add them to aarch64/jdk8u and then merge that into the Shenandoah tree, rather than applying directly to Shenandoah. That way, all three trees (the two aarch64 project ones and the Shenandoah project one) have these fixes. > > -Aleksey > > 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 daniel.daugherty at oracle.com Wed Jun 13 14:54:10 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Jun 2018 10:54:10 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: Andrey and Andrew, I've copied the three previous emails on this thread to: https://bugs.openjdk.java.net/browse/JDK-8153107 This particular hang was never seen on any of Oracle's other supported platforms so I'm a bit hesitant on making a change to shared code without a better understand of why. Dan On 6/13/18 10:00 AM, Andrey Petushkov wrote: >> On 13 Jun 2018, at 16:37, Andrew Haley wrote: >> >> On 06/13/2018 01:40 PM, Andrey Petushkov wrote: >> >>> It looks like the cause of the >>> https://bugs.openjdk.java.net/browse/JDK-8153107 >>> problem is that >>> ObjectSynchronizer::quick_enter implementation leaves the BasicLock >>> marked as recursive (DHW==0) in case that the lock is inflated and >>> already taken. As such the routines which first check the recursive >>> stack locking (e.g. fast_exit) consider this lock as non-inflated >>> recursive and hence do not decrement _recursions field of >>> ObjectMonitor, leaving the monitor locked forever. In contrary the >>> slow path does work the right way: ObjectSynchronizer::slow_enter >>> first marks stack lock as non-locked and non-recursive (DHW==3) and >>> then delegates to ObjectMonitor::enter to increment _recursions. >>> So from the source code prospective this bug looks like >>> platform-independent, contrary to what?s was found under >>> https://bugs.openjdk.java.net/browse/JDK-8131715 >>> . Unfortunately I >>> cannot prove it with an example. The only case it fails for me is >>> runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on >>> aarch32 openjdk port. The following changes fix the problem: >> Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 >> and ARM32 ports. This bug was never seen in the AARCH64 open port, >> so the workaround shouldn't be enabled for it. >> >> 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems >> Reviewed-by: dcubed >> diff -r afd6ae4fec81 -r 71d7ced6c439 hotspot/src/share/vm/runtime/sharedRuntime.cpp >> --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 11:53:20 2016 +0530 >> +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 10:44:17 2016 -0400 >> @@ -1983,8 +1983,10 @@ >> // Handles the uncommon case in locking, i.e., contention or an inflated lock. >> JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) >> // Disable ObjectSynchronizer::quick_enter() in default config >> - // on AARCH64 until JDK-8153107 is resolved. >> - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { >> + // on AARCH64 and ARM until JDK-8153107 is resolved. >> + if (ARM_ONLY((SyncFlags & 256) != 0 &&) >> + AARCH64_ONLY((SyncFlags & 256) != 0 &&) >> + !SafepointSynchronize::is_synchronizing()) { >> // Only try quick_enter() if we're not trying to reach a safepoint >> >> Why did you move the code which handles recursive locking counts? Do >> you believe that it's incorrect where it is, and if so, why? > That?s exactly what I?ve been trying to describe. The displaced header shall be assigned 3 when recursive locking happens on inflated lock. At least with the current design of the exit code which uses it as an indicator that inflated lock is present. > So it seems to me that currently the number of recursive locks on an object is the count of relevant stack lock structures with mark(DHW)!=3 (i.e. first lock + any stack locks prior to inflation) + _recursions field value of the inflated lock structure. The sequence of operations under review was breaking this assumption: any recursion via quick_enter was increasing both number of stack locks with DHW==0 and value of _recursions. While the slow_enter only increased _recursions > The above is idea I got from reading the code, I hope someone more experienced (@Daniel Daugherty?) can chime in and prove me right or wrong > > Andrey >> -- >> 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 Wed Jun 13 15:04:06 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 16:04:06 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: <163d3328-6cc9-1e3e-3a6b-72543b0204db@redhat.com> On 06/13/2018 03:54 PM, Daniel D. Daugherty wrote: > This particular hang was never seen on any of Oracle's other supported > platforms so I'm a bit hesitant on making a change to shared code > without a better understand of why. Yeah, my thoughts exactly. It doesn't help that the platform- specific variants of quick_enter() are all subtly different. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Derek.White at cavium.com Wed Jun 13 15:04:15 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 13 Jun 2018 15:04:15 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: Hi Andrey, Andrew, > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Andrew Haley > On 06/13/2018 01:40 PM, Andrey Petushkov wrote: > > > It looks like the cause of the > > https://bugs.openjdk.java.net/browse/JDK-8153107 > > problem is that > > ObjectSynchronizer::quick_enter implementation leaves the BasicLock > > marked as recursive (DHW==0) in case that the lock is inflated and > > already taken. As such the routines which first check the recursive > > stack locking (e.g. fast_exit) consider this lock as non-inflated > > recursive and hence do not decrement _recursions field of > > ObjectMonitor, leaving the monitor locked forever. In contrary the > > slow path does work the right way: ObjectSynchronizer::slow_enter > > first marks stack lock as non-locked and non-recursive (DHW==3) and > > then delegates to ObjectMonitor::enter to increment _recursions. > > > So from the source code prospective this bug looks like > > platform-independent, contrary to what?s was found under > > https://bugs.openjdk.java.net/browse/JDK-8131715 > > . Unfortunately I > > cannot prove it with an example. The only case it fails for me is > > runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on > > aarch32 openjdk port. The following changes fix the problem: > > Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 > and ARM32 ports. This bug was never seen in the AARCH64 open port, so > the workaround shouldn't be enabled for it. Yes, I've been testing this last week myself (e.g. setting SyncFlags). It's responsible for about a 2% drop in SPECjbb on aarch64 when they added it. > 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP > systems > Reviewed-by: dcubed > diff -r afd6ae4fec81 -r 71d7ced6c439 > hotspot/src/share/vm/runtime/sharedRuntime.cpp > --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 > 11:53:20 2016 +0530 > +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 > 10:44:17 2016 -0400 > @@ -1983,8 +1983,10 @@ > // Handles the uncommon case in locking, i.e., contention or an inflated > lock. > JRT_BLOCK_ENTRY(void, > SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* > lock, JavaThread* thread)) > // Disable ObjectSynchronizer::quick_enter() in default config > - // on AARCH64 until JDK-8153107 is resolved. > - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) > !SafepointSynchronize::is_synchronizing()) { > + // on AARCH64 and ARM until JDK-8153107 is resolved. > + if (ARM_ONLY((SyncFlags & 256) != 0 &&) > + AARCH64_ONLY((SyncFlags & 256) != 0 &&) > + !SafepointSynchronize::is_synchronizing()) { > // Only try quick_enter() if we're not trying to reach a safepoint > > Why did you move the code which handles recursive locking counts? Do you > believe that it's incorrect where it is, and if so, why? I'm similarly suspicious of pointing the blame at the shared code. I'll look some more also. - Derek From aph at redhat.com Wed Jun 13 15:09:12 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 16:09:12 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> Message-ID: <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> On 06/13/2018 04:02 PM, Andrew Hughes wrote: > Clearly though, you want them for Shenandoah earlier than that. In > this case, add them to aarch64/jdk8u and then merge that into the > Shenandoah tree, rather than applying directly to Shenandoah. That > way, all three trees (the two aarch64 project ones and the > Shenandoah project one) have these fixes. Mmm, but that's when *I* start to get nervous about the divergence between what we ship as JDK 8 to everyone and OpenJDK 8 upstream. Of course there's and inevitable tension, but we must be very careful not to break any production systems. -- 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 Wed Jun 13 15:14:58 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 16:14:58 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> Hi Dan, Have you got any torture tests for recursive locking? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Wed Jun 13 15:17:10 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Jun 2018 11:17:10 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> Message-ID: Not at my fingertips, but I will look thru my archives. Dan On 6/13/18 11:14 AM, Andrew Haley wrote: > Hi Dan, > > Have you got any torture tests for recursive locking? > From andrey.petushkov at gmail.com Wed Jun 13 17:26:08 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 20:26:08 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> Message-ID: <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> Ok, I shall I admit I did not dig deep enough. Yes, there is platform specifics which plays a role here. That is: all platforms except Oracle ARM (all bitness) and aarch32 fill-in stack lock?s DHW with result of same-stack-page-lock probe result. Which is always !=0 when failed. Oracle?s ARM and aarch32 do that conditionally, based on whether this test actually passes. Hence for the latter platforms the DHW in the stack lock really contains random value which occasionally can be 0, and being not rewritten (e.g. with markOopDesc::unused_mark(), aka 3) will indicate recursive stack lock for ::fast_unlock(). Not sure about those stack walkers mentioned in the comment in ::quick_enter(). So, right, it?s possible to fix the problem in the platform-specific code only. Leaving up to you to decide whether it?s proper design :) Regards, Andrey > On 13 Jun 2018, at 18:17, Daniel D. Daugherty wrote: > > Not at my fingertips, but I will look thru my archives. > > Dan > > > On 6/13/18 11:14 AM, Andrew Haley wrote: >> Hi Dan, >> >> Have you got any torture tests for recursive locking? >> > From dnuechte at amperecomputing.com Wed Jun 13 17:32:54 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Wed, 13 Jun 2018 17:32:54 +0000 Subject: [aarch64-port-dev ] barrier use in JDK11 Message-ID: I work for Ampere Computing, and am looking at the C2 code produced for some simple JMH benchmarks. The code produced from jdk11 seems to have many more DMBs than the jdk8u Aarch64 port. I think this is probably related to the controls for using barriers instead of LoadAcquire/StoreRelease for volatile variables. I want to switch the "use barriers for volatile variable switch", but I wanted to know more about why it is there, and what the pitfalls might be. Any suggestions/comments? Thanks, Dave From aph at redhat.com Wed Jun 13 17:58:56 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 18:58:56 +0100 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: References: Message-ID: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> On 06/13/2018 06:32 PM, Dave Nuechterlein wrote: I work for Ampere > Computing, and am looking at the C2 code produced for some simple > JMH benchmarks. The code produced from jdk11 seems to have many > more DMBs than the jdk8u Aarch64 port. I think this is probably > related to the controls for using barriers instead of > LoadAcquire/StoreRelease for volatile variables. I want to switch > the "use barriers for volatile variable switch", but I wanted to > know more about why it is there, and what the pitfalls might be. > > Any suggestions/comments? Hard to say. Please post an example; please make it the shortest one you can find. If the examples are too big, please put them on a web site somewhere. It helps a lot to use a debug build. -- 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 Wed Jun 13 18:38:42 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Jun 2018 19:38:42 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> Message-ID: On 13 June 2018 at 16:09, Andrew Haley wrote: > On 06/13/2018 04:02 PM, Andrew Hughes wrote: > >> Clearly though, you want them for Shenandoah earlier than that. In >> this case, add them to aarch64/jdk8u and then merge that into the >> Shenandoah tree, rather than applying directly to Shenandoah. That >> way, all three trees (the two aarch64 project ones and the >> Shenandoah project one) have these fixes. > > Mmm, but that's when *I* start to get nervous about the divergence > between what we ship as JDK 8 to everyone and OpenJDK 8 upstream. Of > course there's and inevitable tension, but we must be very careful not > to break any production systems. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 Indeed, which is why I want them to have more scrutiny by going into aarch64/jdk8u on their own, rather than being part of a huge Shenandoah merge which only goes into aarch64/jdk8u-shenandoah. I completely missed them in the Shenandoah merge until they conflicted with us applying one of them already in our RPMs. I also wouldn't suggest including patches that aren't already in OpenJDK 8 upstream. What we're talking about is fast-tracking patches that are of high priority to us, rather than deviating from OpenJDK 8 long term. The way we build our RPMs is that we use the aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and aarch64/jdk8u on all other architectures. If patches are only included in the former, we introduce the risk of seeing breakage on some architectures, but not others, which can create further confusion. -- 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 aph at redhat.com Thu Jun 14 08:10:00 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 09:10:00 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> Message-ID: On 06/13/2018 07:38 PM, Andrew Hughes wrote: > On 13 June 2018 at 16:09, Andrew Haley wrote: >> On 06/13/2018 04:02 PM, Andrew Hughes wrote: >> >>> Clearly though, you want them for Shenandoah earlier than that. In >>> this case, add them to aarch64/jdk8u and then merge that into the >>> Shenandoah tree, rather than applying directly to Shenandoah. That >>> way, all three trees (the two aarch64 project ones and the >>> Shenandoah project one) have these fixes. >> >> Mmm, but that's when *I* start to get nervous about the divergence >> between what we ship as JDK 8 to everyone and OpenJDK 8 upstream. Of >> course there's and inevitable tension, but we must be very careful not >> to break any production systems. > > Indeed, which is why I want them to have more scrutiny by going into > aarch64/jdk8u > on their own, rather than being part of a huge Shenandoah merge which only goes > into aarch64/jdk8u-shenandoah. I completely missed them in the Shenandoah merge > until they conflicted with us applying one of them already in our RPMs. I see. OK, so we need to split such commits very carefully. > I also wouldn't suggest including patches that aren't already in OpenJDK 8 > upstream. What we're talking about is fast-tracking patches that are of > high priority to us, rather than deviating from OpenJDK 8 long term. Right. Or, I guess upstream patches which are Shenandoah dependencies. > The way we build our RPMs is that we use the > aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and > aarch64/jdk8u on all other architectures. Why do we still do that? Should we review that policy? The only other architectures are, what, PPC and S/390? > If patches are only included in the former, we introduce the risk of > seeing breakage on some architectures, but not others, which can > create further confusion. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Jun 14 08:21:43 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Jun 2018 10:21:43 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> Message-ID: <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> On Thu, 2018-06-14 at 09:10 +0100, Andrew Haley wrote: > > The way we build our RPMs is that we use the > > aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and > > aarch64/jdk8u on all other architectures. > > Why do we still do that? Because shenandoah only works on aarch64 and x86_64. -XX:+UseShenandoahGC on unsupported arches would need to get disabled at runtime. Thanks, Severin From aph at redhat.com Thu Jun 14 08:22:30 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 09:22:30 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> Message-ID: <4b0a54a1-6660-4ef8-2c68-0f5a0f185cd0@redhat.com> On 06/14/2018 09:21 AM, Severin Gehwolf wrote: > On Thu, 2018-06-14 at 09:10 +0100, Andrew Haley wrote: >>> The way we build our RPMs is that we use the >>> aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and >>> aarch64/jdk8u on all other architectures. >> >> Why do we still do that? > > Because shenandoah only works on aarch64 and x86_64. > > -XX:+UseShenandoahGC on unsupported arches would need to get disabled > at runtime. Yes. But that doesn't explain why we use different repos. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Jun 14 08:36:51 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Jun 2018 10:36:51 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <4b0a54a1-6660-4ef8-2c68-0f5a0f185cd0@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> <4b0a54a1-6660-4ef8-2c68-0f5a0f185cd0@redhat.com> Message-ID: On Thu, 2018-06-14 at 09:22 +0100, Andrew Haley wrote: > On 06/14/2018 09:21 AM, Severin Gehwolf wrote: > > On Thu, 2018-06-14 at 09:10 +0100, Andrew Haley wrote: > > > > The way we build our RPMs is that we use the > > > > aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and > > > > aarch64/jdk8u on all other architectures. > > > > > > Why do we still do that? > > > > Because shenandoah only works on aarch64 and x86_64. > > > > -XX:+UseShenandoahGC on unsupported arches would need to get disabled > > at runtime. > > Yes. But that doesn't explain why we use different repos. I'm confused. That's the approach we took to get Shenandoah support on aarch64 and x86_64. How do you suggest to change it? Use aarch64/shenandoah-jdk8u (the entire forest, not just hotspot) for all arches? Thanks, Severin From aph at redhat.com Thu Jun 14 09:18:05 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 10:18:05 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> <4b0a54a1-6660-4ef8-2c68-0f5a0f185cd0@redhat.com> Message-ID: <8ca4bb9e-7e8a-4b35-d89d-03440e0320ed@redhat.com> On 06/14/2018 09:36 AM, Severin Gehwolf wrote: > On Thu, 2018-06-14 at 09:22 +0100, Andrew Haley wrote: >> On 06/14/2018 09:21 AM, Severin Gehwolf wrote: >>> On Thu, 2018-06-14 at 09:10 +0100, Andrew Haley wrote: >>>>> The way we build our RPMs is that we use the >>>>> aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and >>>>> aarch64/jdk8u on all other architectures. >>>> >>>> Why do we still do that? >>> >>> Because shenandoah only works on aarch64 and x86_64. >>> >>> -XX:+UseShenandoahGC on unsupported arches would need to get disabled >>> at runtime. >> >> Yes. But that doesn't explain why we use different repos. > > I'm confused. That's the approach we took to get Shenandoah support on > aarch64 and x86_64. How do you suggest to change it? Use > aarch64/shenandoah-jdk8u (the entire forest, not just hotspot) for all > arches? What is the advantage of now using a different repo for the minority architectures? When it was first proposed to use a different repo for Shenandoah HotSpot the idea was that customers not using Shenandoah would be using a non-Shenandoah HotSpot. The Java launcher would only load the Shenandoah libjvm.so when needed. But as we aren't doing that (are we?) there's no point. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Jun 14 09:44:24 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Jun 2018 11:44:24 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <8ca4bb9e-7e8a-4b35-d89d-03440e0320ed@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> <4b0a54a1-6660-4ef8-2c68-0f5a0f185cd0@redhat.com> <8ca4bb9e-7e8a-4b35-d89d-03440e0320ed@redhat.com> Message-ID: <0728d2f8b31b4017e301938da5675247cb3ed1e6.camel@redhat.com> On Thu, 2018-06-14 at 10:18 +0100, Andrew Haley wrote: > On 06/14/2018 09:36 AM, Severin Gehwolf wrote: > > On Thu, 2018-06-14 at 09:22 +0100, Andrew Haley wrote: > > > On 06/14/2018 09:21 AM, Severin Gehwolf wrote: > > > > On Thu, 2018-06-14 at 09:10 +0100, Andrew Haley wrote: > > > > > > The way we build our RPMs is that we use the > > > > > > aarch64/shenandoah-jdk8u HotSpot on aarch64 & x86_64 and > > > > > > aarch64/jdk8u on all other architectures. > > > > > > > > > > Why do we still do that? > > > > > > > > Because shenandoah only works on aarch64 and x86_64. > > > > > > > > -XX:+UseShenandoahGC on unsupported arches would need to get disabled > > > > at runtime. > > > > > > Yes. But that doesn't explain why we use different repos. > > > > I'm confused. That's the approach we took to get Shenandoah support on > > aarch64 and x86_64. How do you suggest to change it? Use > > aarch64/shenandoah-jdk8u (the entire forest, not just hotspot) for all > > arches? > > What is the advantage of now using a different repo for the minority > architectures? I suppose only that non-shendandoah arches get hotspot without added C2 code for shenandoah. There might be some other things I'm missing... > When it was first proposed to use a different repo for > Shenandoah HotSpot the idea was that customers not using Shenandoah > would be using a non-Shenandoah HotSpot. The Java launcher would only > load the Shenandoah libjvm.so when needed. But as we aren't doing > that (are we?) there's no point. Interesting. That is news to me. First, we aren't doing that currently. Second, in order to implement this we'd need to do some build and launcher hacks to get this working. It implies shipping two different libjvm.so's for aarch64 and x86_64. AFAIK, we don't do that. As to why we haven't done what you describe above (dynamic selection of libjvm.so based on GC config) is probably a case of got-lost-in- communication :-/ One person thinking that's what was meant, another person thinking something different. Thanks, Severin From aph at redhat.com Thu Jun 14 09:53:40 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 10:53:40 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration of Shenandoah 2018-05-15 In-Reply-To: <0728d2f8b31b4017e301938da5675247cb3ed1e6.camel@redhat.com> References: <5315ca0e-5bee-c1ce-f5b3-0261556a8295@redhat.com> <7c28539f-c931-1185-31b2-945d2bb3df54@redhat.com> <06a01678c7e5f343a675f38b9828fe11002c2bc5.camel@redhat.com> <4b0a54a1-6660-4ef8-2c68-0f5a0f185cd0@redhat.com> <8ca4bb9e-7e8a-4b35-d89d-03440e0320ed@redhat.com> <0728d2f8b31b4017e301938da5675247cb3ed1e6.camel@redhat.com> Message-ID: On 06/14/2018 10:44 AM, Severin Gehwolf wrote: > On Thu, 2018-06-14 at 10:18 +0100, Andrew Haley wrote: > >> When it was first proposed to use a different repo for >> Shenandoah HotSpot the idea was that customers not using Shenandoah >> would be using a non-Shenandoah HotSpot. The Java launcher would only >> load the Shenandoah libjvm.so when needed. But as we aren't doing >> that (are we?) there's no point. > > Interesting. That is news to me. First, we aren't doing that currently. > Second, in order to implement this we'd need to do some build and > launcher hacks to get this working. It implies shipping two different > libjvm.so's for aarch64 and x86_64. AFAIK, we don't do that. It never happened because I was persuaded that it was unnecessary. This is because none of the Shenandoah code is enabled unless UseShenandoahGC is a command line option. But if we're seeing significant divergence between the Shenandoah repo and the upstream repo in non-Shenandoah-related areas, then Houston, we have a problem. > As to why we haven't done what you describe above (dynamic selection of > libjvm.so based on GC config) is probably a case of got-lost-in- > communication :-/ One person thinking that's what was meant, another > person thinking something different. As I said: I was persuaded it was unnecessary. But it's only unnecessary as long as we are utterly scrupulous about keeping the AArch64 Shenandoah repos perfectly clean. If Shenandoah actually requires some fixes from upstream we can look at them to make sure they are low risk, but that's all. -- 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 Thu Jun 14 11:36:03 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Thu, 14 Jun 2018 14:36:03 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: <1e8c2ee8-1448-a04c-1ef0-461b0392dc83@samersoff.net> David, When we constructing frame [1] we get interpreter_frame_sender_sp from fp()[unextended_sp_offset = -1] and store it as _unextended_sp. Previously, interpreter stored caller_sp there. But it's possible that caller_sp is below or above sp of current frame. One of such cases is a top level frame when we iterate frames from JVM_GetStackAccessControlContext. Iteration of recursive frames from JFR FullStackTrace is the other case. 1. frame frame::sender_for_interpreter_frame(RegisterMap* map) const { // SP is the raw SP from the sender after adapter or interpreter // extension. intptr_t* sender_sp = this->sender_sp(); // This is the sp before any possible extension (adapter/locals). intptr_t* unextended_sp = interpreter_frame_sender_sp(); ... // sender_sp intptr_t* frame::interpreter_frame_sender_sp() const { assert(is_interpreted_frame(), "interpreted frame expected"); return (intptr_t*) at(interpreter_frame_sender_sp_offset); } -Dmitry\S On 11.06.2018 00:05, David Holmes wrote: > Hi Dmitry, > > I have to admit I still can't connect all the pieces here. When we are > operating in frame::safe_for_sender, what has set _unextended_sp? Can > you walk through a complete example? I can't quite connect Andrew's > example to the original problem. > > It still seems to me that the current frame should have: > > sp <= unextended_sp <= stack_base() > > ?? > > Thanks, > David > > On 11/06/2018 2:54 AM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> Please, review updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 >> >> CR link: >> >> https://bugs.openjdk.java.net/browse/JDK-8203481 >> >> -Dmitry >> >> On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: >>> Hello Everybody, >>> >>> Please review small fix >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >>> >>> CR: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8203481 >>> >>> Testing: >>> >>> jfr tests that depends to safe_for_sender functionality >>> >>> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >>> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >>> >>> fails on AARCH64. >>> >>> These tests passed after the fix. >>> >>> >> >> -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From andrey.petushkov at gmail.com Thu Jun 14 11:59:11 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jun 2018 14:59:11 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> Message-ID: So then if you prefer to leave the different logic in shared code between quick and slow paths I believe the fix for cpu/arm implementation (and removal of unnecessary workaround for cpu/aarch64) should look like this: --- CUT --- diff -r db65921e9a9b src/hotspot/cpu/arm/macroAssembler_arm.cpp --- a/src/hotspot/cpu/arm/macroAssembler_arm.cpp Thu Jun 07 06:27:09 2018 -0400 +++ b/src/hotspot/cpu/arm/macroAssembler_arm.cpp Thu Jun 14 14:56:38 2018 +0300 @@ -3014,8 +3014,8 @@ mov(Rscratch, SP); sub(Rscratch, Rmark, Rscratch); ands(Rscratch, Rscratch, imm); - b(done, ne); // exit with failure - str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); // set to zero + // set to zero if recursive lock, set to non zero otherwise (see discussion in JDK-8153107) + str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); b(done); #else @@ -3025,7 +3025,8 @@ sub(Rscratch, Rmark, SP, eq); movs(Rscratch, AsmOperand(Rscratch, lsr, exact_log2(os::vm_page_size())), eq); // If still 'eq' then recursive locking OK - str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero + // set to zero if recursive lock, set to non zero otherwise (see discussion in JDK-8153107) + str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); b(done); #endif diff -r db65921e9a9b src/hotspot/share/runtime/sharedRuntime.cpp --- a/src/hotspot/share/runtime/sharedRuntime.cpp Thu Jun 07 06:27:09 2018 -0400 +++ b/src/hotspot/share/runtime/sharedRuntime.cpp Thu Jun 14 14:56:38 2018 +0300 @@ -1983,11 +1983,7 @@ // Handles the uncommon case in locking, i.e., contention or an inflated lock. JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) - // Disable ObjectSynchronizer::quick_enter() in default config - // on AARCH64 and ARM until JDK-8153107 is resolved. - if (ARM_ONLY((SyncFlags & 256) != 0 &&) - AARCH64_ONLY((SyncFlags & 256) != 0 &&) - !SafepointSynchronize::is_synchronizing()) { + if (!SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint // so that the calling thread reaches the safepoint more quickly. if (ObjectSynchronizer::quick_enter(_obj, thread, lock)) return; --- END CUT --- Tested on jdk10/port-aarch32 codebase Regards, Andrey On Wed, Jun 13, 2018 at 8:26 PM Andrey Petushkov wrote: > Ok, I shall I admit I did not dig deep enough. Yes, there is platform > specifics which plays a role here. That is: all platforms except Oracle ARM > (all bitness) and aarch32 fill-in stack lock?s DHW with result of > same-stack-page-lock probe result. Which is always !=0 when failed. > Oracle?s ARM and aarch32 do that conditionally, based on whether this test > actually passes. Hence for the latter platforms the DHW in the stack lock > really contains random value which occasionally can be 0, and being not > rewritten (e.g. with markOopDesc::unused_mark(), aka 3) will indicate > recursive stack lock for ::fast_unlock(). Not sure about those stack > walkers mentioned in the comment in ::quick_enter(). So, right, it?s > possible to fix the problem in the platform-specific code only. Leaving up > to you to decide whether it?s proper design :) > > Regards, > Andrey > > > On 13 Jun 2018, at 18:17, Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > > > > Not at my fingertips, but I will look thru my archives. > > > > Dan > > > > > > On 6/13/18 11:14 AM, Andrew Haley wrote: > >> Hi Dan, > >> > >> Have you got any torture tests for recursive locking? > >> > > > > From aph at redhat.com Thu Jun 14 12:14:58 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 13:14:58 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> Message-ID: <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > So then if you prefer to leave the different logic in shared code between > quick and slow paths I believe the fix for cpu/arm implementation (and > removal of unnecessary workaround for cpu/aarch64) should look like this: Something awful happened to the formatting of your mail. Can you put it up somewhere we can see the patch? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Thu Jun 14 12:25:01 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jun 2018 15:25:01 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hm, strange. It displays well for me in the archives page. Anyway, I've put the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley wrote: > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > So then if you prefer to leave the different logic in shared code between > > quick and slow paths I believe the fix for cpu/arm implementation (and > > removal of unnecessary workaround for cpu/aarch64) should look like this: > > Something awful happened to the formatting of your mail. Can you put > it up somewhere we can see the patch? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > F A671 > From Joshua.Zhu at arm.com Thu Jun 14 13:26:37 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Thu, 14 Jun 2018 13:26:37 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest Message-ID: Hi, Please review the following change. Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 Webrev: http://cr.openjdk.java.net/~zyao/8205004/ This bug causes three failures in Jtreg ArraysEqCmpTest. test ArraysEqCmpTest.testArray(byte[]) test ArraysEqCmpTest.testArray(unsigned byte[]) test ArraysEqCmpTest.testArray(char[]) Array length needs to be compared for short arrays. Please see detailed description in JBS. Best Regards, Joshua From aph at redhat.com Thu Jun 14 13:34:07 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 14:34:07 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: Message-ID: On 06/14/2018 02:26 PM, Joshua Zhu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 > Webrev: http://cr.openjdk.java.net/~zyao/8205004/ > > This bug causes three failures in Jtreg ArraysEqCmpTest. > test ArraysEqCmpTest.testArray(byte[]) > test ArraysEqCmpTest.testArray(unsigned byte[]) > test ArraysEqCmpTest.testArray(char[]) > > Array length needs to be compared for short arrays. > Please see detailed description in JBS. Its this just a regular jtreg test? I'm wondering how we missed 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 Thu Jun 14 13:44:03 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 14:44:03 +0100 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: <5a15ca84-e0a8-9cac-85f5-b5cdce5a4535@redhat.com> On 06/10/2018 10:05 PM, David Holmes wrote: > I have to admit I still can't connect all the pieces here. When we are > operating in frame::safe_for_sender, what has set _unextended_sp? Can > you walk through a complete example? I can't quite connect Andrew's > example to the original problem. > > It still seems to me that the current frame should have: > > sp <= unextended_sp <= stack_base() No. We save SP, then remove unused stack, then call int a method. The address saved into the current method is the old SP, before stack items were removed. This is refereed to as the "unextended_sp" in th eshared code, but it's actually *below* the SP when a method was entered. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Jun 14 14:30:53 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 14 Jun 2018 17:30:53 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: Message-ID: <4a80b935-932a-760b-42fc-c07eb9017b20@bell-sw.com> Hi, I think you can just move existing checks: 5148 cmp(cnt2, cnt1); 5149 br(NE, DONE); and 5141 cmpoop(a1, a2); 5142 br(EQ, SAME); before jump to short case: 5140 br(LE, SHORT); // short or same Then you don't need to add any additional code. (cmpoop(a1, a2) check should go first, because cnt1 and cnt2 loads are possibly still executed) Thanks, Dmitrij On 14.06.2018 16:26, Joshua Zhu wrote: > Hi, > > Please review the following change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 > Webrev: http://cr.openjdk.java.net/~zyao/8205004/ > > This bug causes three failures in Jtreg ArraysEqCmpTest. > test ArraysEqCmpTest.testArray(byte[]) > test ArraysEqCmpTest.testArray(unsigned byte[]) > test ArraysEqCmpTest.testArray(char[]) > > Array length needs to be compared for short arrays. > Please see detailed description in JBS. > > Best Regards, > Joshua > From dmitrij.pochepko at bell-sw.com Thu Jun 14 14:31:43 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 14 Jun 2018 17:31:43 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: Message-ID: On 14.06.2018 16:34, Andrew Haley wrote: > On 06/14/2018 02:26 PM, Joshua Zhu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 >> Webrev: http://cr.openjdk.java.net/~zyao/8205004/ >> >> This bug causes three failures in Jtreg ArraysEqCmpTest. >> test ArraysEqCmpTest.testArray(byte[]) >> test ArraysEqCmpTest.testArray(unsigned byte[]) >> test ArraysEqCmpTest.testArray(char[]) >> >> Array length needs to be compared for short arrays. >> Please see detailed description in JBS. > Its this just a regular jtreg test? I'm wondering how we missed > it. > It's not a hotspot jtreg test(hotspot jtreg tests has no such testcase). It's jdk jtreg test (java/util). That is the reason. From aph at redhat.com Thu Jun 14 14:33:53 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 15:33:53 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: Message-ID: <74df4c30-4040-ef4e-c6f8-86b65a4d7f8d@redhat.com> On 06/14/2018 03:31 PM, Dmitrij Pochepko wrote: > > > On 14.06.2018 16:34, Andrew Haley wrote: >> On 06/14/2018 02:26 PM, Joshua Zhu wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 >>> Webrev: http://cr.openjdk.java.net/~zyao/8205004/ >>> >>> This bug causes three failures in Jtreg ArraysEqCmpTest. >>> test ArraysEqCmpTest.testArray(byte[]) >>> test ArraysEqCmpTest.testArray(unsigned byte[]) >>> test ArraysEqCmpTest.testArray(char[]) >>> >>> Array length needs to be compared for short arrays. >>> Please see detailed description in JBS. >> Its this just a regular jtreg test? I'm wondering how we missed >> it. >> > It's not a hotspot jtreg test(hotspot jtreg tests has no such testcase). > It's jdk jtreg test (java/util). That is the reason. So is it the case, then, that you aren't running jdk jtreg tests when you write intrinsics? Maybe you should start, -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Derek.White at cavium.com Thu Jun 14 18:12:57 2018 From: Derek.White at cavium.com (White, Derek) Date: Thu, 14 Jun 2018 18:12:57 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hi Andrey, I like this version. My only suggestion is minor - the "ands" at line 3016 could be a simple "and". It causes no harm but could be confusing to a reader: 3016 ands(Rscratch, Rscratch, imm); No need to see a new webrev. - Derek > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Andrey Petushkov > Sent: Thursday, June 14, 2018 8:25 AM > To: Andrew Haley > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; AArch32 Port Project dev at openjdk.java.net> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > External Email > > Hm, strange. It displays well for me in the archives page. Anyway, I've put > the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley wrote: > > > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > > So then if you prefer to leave the different logic in shared code > > > between quick and slow paths I believe the fix for cpu/arm > > > implementation (and removal of unnecessary workaround for > cpu/aarch64) should look like this: > > > > Something awful happened to the formatting of your mail. Can you put > > it up somewhere we can see the patch? > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > > F A671 > > From aph at redhat.com Thu Jun 14 19:37:00 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 20:37:00 +0100 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: References: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> Message-ID: <0f4b1cea-56e2-d71e-f775-c8ab1426dd83@redhat.com> On 06/14/2018 06:59 PM, Dave Nuechterlein wrote: > I suspect the issue is that there are no customizations for xgene3/emag1 in cpu/aarch64/vm_version_aarch64.cpp. It certainly could be that. > Are there any guidelines or best practices on how to do an initial vm_version variant? What test should I run before submitting a patch, etc. As long as your processor supports proper lrar/stlr you're good. Test it with jcstress. Make sure that UseBarriersForVolatile is off. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dnuechte at amperecomputing.com Thu Jun 14 17:59:57 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Thu, 14 Jun 2018 17:59:57 +0000 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> References: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> Message-ID: This is an example from JMH stub code. In jdk8, the ldrb is a ldarb because it is accessing the "isDone" volatile variable. Here is it a ldrb followed by a dmb inner, load. There is no dmb ish in the loop on jdk8 either. 0x0000ffff81a1d9dc: ldr x4, [sp,#112] 0x0000ffff81a1d9e0: add x0, x4, #0x1 ;; membar 0x0000ffff81a1d9e4: dmb ish 0x0000ffff81a1d9e8: ldr x1, [sp,#120] 0x0000ffff81a1d9ec: ldrb w2, [x1,#148] ; implicit exception: dispatches to 0x0000ffff81a1dc64 0x0000ffff81a1d9f0: dmb ishld ;*getfield isDone {reexecute=0 rethrow=0 return_oop=0} ; - com.ampere.pipeline_int_mvn.generated.MyBenchmark_test_method_jmhTest::test_method_avgt_jmhStub at 27 (line 188) I suspect the issue is that there are no customizations for xgene3/emag1 in cpu/aarch64/vm_version_aarch64.cpp. Are there any guidelines or best practices on how to do an initial vm_version variant? What test should I run before submitting a patch, etc. -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Wednesday, June 13, 2018 11:59 AM To: Dave Nuechterlein ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] barrier use in JDK11 On 06/13/2018 06:32 PM, Dave Nuechterlein wrote: I work for Ampere > Computing, and am looking at the C2 code produced for some simple JMH > benchmarks. The code produced from jdk11 seems to have many more DMBs > than the jdk8u Aarch64 port. I think this is probably related to the > controls for using barriers instead of LoadAcquire/StoreRelease for > volatile variables. I want to switch the "use barriers for volatile > variable switch", but I wanted to know more about why it is there, and > what the pitfalls might be. > > Any suggestions/comments? Hard to say. Please post an example; please make it the shortest one you can find. If the examples are too big, please put them on a web site somewhere. It helps a lot to use a debug build. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Thu Jun 14 20:49:06 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jun 2018 16:49:06 -0400 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: On 6/10/18 12:54 PM, Dmitry Samersoff wrote: > Hello Everybody, > > Please, review updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 This is still very confusing. In one part of this thread, we're talking like this is ARM only fix because X64 does things differently. In another part of this thread, we're talking like this bug affects all platforms, but I haven't seen failures on X64 due to this so...? Something is still not making sense here. The patch itself is inconsistent between platforms. Here's the key logic line in all four platforms: +? bool unextended_sp_safe = (unextended_sp < thread->stack_base()); +???????????????????????????? (unextended_sp <= thread->stack_base())); +? bool unextended_sp_safe = (_UNEXTENDED_SP <= thread->stack_base()); +? bool unextended_sp_safe = (unextended_sp < thread->stack_base()); Two platforms use '<' and two use '<='. Dan > > CR link: > > https://bugs.openjdk.java.net/browse/JDK-8203481 > > -Dmitry > > On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> Please review small fix >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >> >> CR: >> >> https://bugs.openjdk.java.net/browse/JDK-8203481 >> >> Testing: >> >> jfr tests that depends to safe_for_sender functionality >> >> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >> >> fails on AARCH64. >> >> These tests passed after the fix. >> >> > From daniel.daugherty at oracle.com Thu Jun 14 20:50:15 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jun 2018 16:50:15 -0400 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: <909b6f6a-0375-ba12-fab3-a66875a36122@oracle.com> On 6/10/18 5:05 PM, David Holmes wrote: > Hi Dmitry, > > I have to admit I still can't connect all the pieces here. When we are > operating in frame::safe_for_sender, what has set _unextended_sp? Can > you walk through a complete example? I can't quite connect Andrew's > example to the original problem. > > It still seems to me that the current frame should have: > > sp <= unextended_sp <= stack_base() David, you and I are in agreement here. At least I'm in agreement for X64 (and SPARC). Dan > > ?? > > Thanks, > David > > On 11/06/2018 2:54 AM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> Please, review updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 >> >> CR link: >> >> https://bugs.openjdk.java.net/browse/JDK-8203481 >> >> -Dmitry >> >> On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: >>> Hello Everybody, >>> >>> Please review small fix >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >>> >>> CR: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8203481 >>> >>> Testing: >>> >>> jfr tests that depends to safe_for_sender functionality >>> >>> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >>> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >>> >>> fails on AARCH64. >>> >>> These tests passed after the fix. >>> >>> >> >> > From andrey.petushkov at gmail.com Thu Jun 14 20:54:47 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jun 2018 23:54:47 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hi Derek, that shall be ands since it expected to leave the result in the flags register, see the cmpFastLock instruct in aarch64.ad to my taste this version is error-prone, since it's quite hard to deduce that contract FastLock node involves writing of non 0 value into DHW of stack lock when it has failed. however I don't insist. so if everyone agrees could someone please commit. sorry, I don't have necessary status Regards, Andrey On Thu, Jun 14, 2018 at 9:13 PM White, Derek wrote: > Hi Andrey, > > I like this version. > > My only suggestion is minor - the "ands" at line 3016 could be a simple > "and". It causes no harm but could be confusing to a reader: > > 3016 ands(Rscratch, Rscratch, imm); > > No need to see a new webrev. > - Derek > > > -----Original Message----- > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > bounces at openjdk.java.net] On Behalf Of Andrey Petushkov > > Sent: Thursday, June 14, 2018 8:25 AM > > To: Andrew Haley > > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > > dev at openjdk.java.net; AArch32 Port Project > dev at openjdk.java.net> > > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > > > External Email > > > > Hm, strange. It displays well for me in the archives page. Anyway, I've > put > > the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > > > On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley wrote: > > > > > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > > > So then if you prefer to leave the different logic in shared code > > > > between quick and slow paths I believe the fix for cpu/arm > > > > implementation (and removal of unnecessary workaround for > > cpu/aarch64) should look like this: > > > > > > Something awful happened to the formatting of your mail. Can you put > > > it up somewhere we can see the patch? > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > > > F A671 > > > > From daniel.daugherty at oracle.com Thu Jun 14 20:56:36 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jun 2018 16:56:36 -0400 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <1e8c2ee8-1448-a04c-1ef0-461b0392dc83@samersoff.net> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <1e8c2ee8-1448-a04c-1ef0-461b0392dc83@samersoff.net> Message-ID: On 6/14/18 7:36 AM, Dmitry Samersoff wrote: > David, > > When we constructing frame [1] we get interpreter_frame_sender_sp from > fp()[unextended_sp_offset = -1] and store it as _unextended_sp. > > Previously, interpreter stored caller_sp there. > > But it's possible that caller_sp is below or above sp of current frame. That last sentence is not making sense to me. At least on X64, that last sentence doesn't make sense to me. So I'm in an interpreter frame and I have a caller SP value saved in my frame. I'm about to make a call (create a new frame) and you are saying that the current sp in my current frame might be below or above the saved caller SP value. I expect it to be below where below means cur SP <= saved caller SP. Dan > > One of such cases is a top level frame when we iterate frames from > JVM_GetStackAccessControlContext. Iteration of recursive frames from JFR > FullStackTrace is the other case. > > > 1. > > frame frame::sender_for_interpreter_frame(RegisterMap* map) const { > // SP is the raw SP from the sender after adapter or interpreter > // extension. > intptr_t* sender_sp = this->sender_sp(); > > // This is the sp before any possible extension (adapter/locals). > intptr_t* unextended_sp = interpreter_frame_sender_sp(); > > ... > > // sender_sp > intptr_t* frame::interpreter_frame_sender_sp() const { > assert(is_interpreted_frame(), "interpreted frame expected"); > return (intptr_t*) at(interpreter_frame_sender_sp_offset); > } > > -Dmitry\S > > > > On 11.06.2018 00:05, David Holmes wrote: >> Hi Dmitry, >> >> I have to admit I still can't connect all the pieces here. When we are >> operating in frame::safe_for_sender, what has set _unextended_sp? Can >> you walk through a complete example? I can't quite connect Andrew's >> example to the original problem. >> >> It still seems to me that the current frame should have: >> >> sp <= unextended_sp <= stack_base() >> >> ?? >> >> Thanks, >> David >> >> On 11/06/2018 2:54 AM, Dmitry Samersoff wrote: >>> Hello Everybody, >>> >>> Please, review updated webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 >>> >>> CR link: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8203481 >>> >>> -Dmitry >>> >>> On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: >>>> Hello Everybody, >>>> >>>> Please review small fix >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >>>> >>>> CR: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8203481 >>>> >>>> Testing: >>>> >>>> jfr tests that depends to safe_for_sender functionality >>>> >>>> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >>>> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >>>> >>>> fails on AARCH64. >>>> >>>> These tests passed after the fix. >>>> >>>> >>> > From daniel.daugherty at oracle.com Thu Jun 14 21:02:54 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jun 2018 17:02:54 -0400 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <5a15ca84-e0a8-9cac-85f5-b5cdce5a4535@redhat.com> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <5a15ca84-e0a8-9cac-85f5-b5cdce5a4535@redhat.com> Message-ID: <75123f5b-667b-00b9-88c4-f202e0904860@oracle.com> On 6/14/18 9:44 AM, Andrew Haley wrote: > On 06/10/2018 10:05 PM, David Holmes wrote: >> I have to admit I still can't connect all the pieces here. When we are >> operating in frame::safe_for_sender, what has set _unextended_sp? Can >> you walk through a complete example? I can't quite connect Andrew's >> example to the original problem. >> >> It still seems to me that the current frame should have: >> >> sp <= unextended_sp <= stack_base() > No. We save SP, then remove unused stack, then call int a method. Where does this "remove unused stack" come from? And is that only an ARM thing? I don't remember seeing that on X64... > The address saved into the current method is the old SP, before stack > items were removed. This is refereed to as the "unextended_sp" in th > eshared code, but it's actually *below* the SP when a method was > entered. I can see how removing things from the stack (and incrementing SP) could result in an SP value > saved SP value. It's the "removing things from the stack" part that has me confused right now... Also, we have a terminology problem in this thread. In this: ??? sp <= unextended_sp <= stack_base() I would say that 'sp' is below (or equal) to unextended_sp and that 'unextended_sp' is below (or equal) to stack_base(). To me "below" is like "less than" and "above" is like "greater than". Dan From Derek.White at cavium.com Thu Jun 14 22:08:36 2018 From: Derek.White at cavium.com (White, Derek) Date: Thu, 14 Jun 2018 22:08:36 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hi Andrey, It took me looking at the code three times, but I finally saw what you mean about condition code register. OK, looks fine to me. You still need a (R)eviewer?s OK and then a sponsor. * Derek From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] Sent: Thursday, June 14, 2018 4:55 PM To: White, Derek Cc: Andrew Haley ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; AArch32 Port Project Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking External Email Hi Derek, that shall be ands since it expected to leave the result in the flags register, see the cmpFastLock instruct in aarch64.ad to my taste this version is error-prone, since it's quite hard to deduce that contract FastLock node involves writing of non 0 value into DHW of stack lock when it has failed. however I don't insist. so if everyone agrees could someone please commit. sorry, I don't have necessary status Regards, Andrey On Thu, Jun 14, 2018 at 9:13 PM White, Derek > wrote: Hi Andrey, I like this version. My only suggestion is minor - the "ands" at line 3016 could be a simple "and". It causes no harm but could be confusing to a reader: 3016 ands(Rscratch, Rscratch, imm); No need to see a new webrev. - Derek > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Andrey Petushkov > Sent: Thursday, June 14, 2018 8:25 AM > To: Andrew Haley > > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; AArch32 Port Project dev at openjdk.java.net> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > External Email > > Hm, strange. It displays well for me in the archives page. Anyway, I've put > the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > wrote: > > > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > > So then if you prefer to leave the different logic in shared code > > > between quick and slow paths I believe the fix for cpu/arm > > > implementation (and removal of unnecessary workaround for > cpu/aarch64) should look like this: > > > > Something awful happened to the formatting of your mail. Can you put > > it up somewhere we can see the patch? > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > > F A671 > > From ci_notify at linaro.org Fri Jun 15 00:16:10 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 15 Jun 2018 00:16:10 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <171337979.2183.1529021771689.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/164/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/11 pass: 3,192; fail: 12; error: 3; not run: 11,616 Build 1: aarch64/2018/may/13 pass: 3,191; fail: 13; error: 3; not run: 11,616 Build 2: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 3: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 4: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 5: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 6: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 7: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 8: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 9: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 10: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 12: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/13 pass: 5,674; fail: 24; error: 2; not run: 11,619 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/11 pass: 7,880; fail: 623; error: 19 Build 1: aarch64/2018/may/13 pass: 7,903; fail: 599; error: 23 Build 2: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 3: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 4: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 5: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 6: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 7: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 8: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 9: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 10: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 11: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 12: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 13: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 Build 14: aarch64/2018/jun/13 pass: 8,435; fail: 576; error: 15 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/11 pass: 3,865; fail: 6 Build 1: aarch64/2018/may/13 pass: 3,862; fail: 6; error: 4 Build 2: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 3: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 4: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 5: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 6: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 7: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 8: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 9: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 10: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 11: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 12: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 13: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 Build 14: aarch64/2018/jun/13 pass: 3,891; fail: 6; error: 2 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/11 pass: 3,199; fail: 12; error: 3; not run: 11,616 Build 1: aarch64/2018/may/13 pass: 3,200; fail: 11; error: 3; not run: 11,616 Build 2: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 3: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 4: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 5: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 6: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 7: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 8: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/13 pass: 5,682; fail: 23; error: 2; not run: 11,619 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/11 pass: 7,912; fail: 592; error: 18 Build 1: aarch64/2018/may/13 pass: 7,892; fail: 616; error: 17 Build 2: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 3: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 4: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 5: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 6: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 7: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 8: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 9: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 10: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 11: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 12: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 13: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 Build 14: aarch64/2018/jun/13 pass: 8,423; fail: 589; error: 15 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/11 pass: 3,860; fail: 6; error: 5 Build 1: aarch64/2018/may/13 pass: 3,861; fail: 6; error: 5 Build 2: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 3: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 4: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 5: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 6: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 7: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 8: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 9: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 10: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 11: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 12: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 13: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 Build 14: aarch64/2018/jun/13 pass: 3,892; fail: 6; error: 1 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): 0.63x Relative performance: Server critical-jOPS (nc): 0.52x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.58, Server: 109.42 Client 66.58 / Client 2014-04-01 (43.00): 1.55x Server 109.42 / Server 2014-04-01 (71.00): 1.54x 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 15 days. 2018-05-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/131/results/ 2018-05-14 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/133/results/ 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ 2018-06-15 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/164/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Joshua.Zhu at arm.com Fri Jun 15 03:50:54 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Fri, 15 Jun 2018 03:50:54 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <4a80b935-932a-760b-42fc-c07eb9017b20@bell-sw.com> References: <4a80b935-932a-760b-42fc-c07eb9017b20@bell-sw.com> Message-ID: Hi Dmitrij, I saw the below comments in original codes. 5137 // on most CPUs a2 is still "locked"(surprisingly) in ldrw and it's 5138 // faster to perform another branch before comparing a1 and a2 before 5139 cmp(cnt1, elem_per_word); 5140 br(LE, SHORT); // short or same and if as the comments say, I think we can move 5141 cmpoop(a1, a2); 5142 br(EQ, SAME); before 5132 cbz(a1, A_IS_NULL); 5133 ldrw(cnt1, Address(a1, length_offset)); 5134 cbz(a2, A_IS_NULL); 5135 ldrw(cnt2, Address(a2, length_offset)); and add additional code: cmp(cnt2, cnt1); br(NE, DONE); in the SHORT path just as my patch did after 5209 bind(SHORT); and label LEN_IS_ZERO and its path can also be deleted like below: bind(SHORT); cmp(cnt2, cnt1); br(NE, DONE); cbz(cnt1, SAME); Best Regards, Joshua > Hi, > > I think you can just move existing checks: > > 5148 cmp(cnt2, cnt1); > 5149 br(NE, DONE); > > and > > 5141 cmpoop(a1, a2); > 5142 br(EQ, SAME); > > before jump to short case: 5140 br(LE, SHORT); // short or same > > Then you don't need to add any additional code. > > (cmpoop(a1, a2) check should go first, because cnt1 and cnt2 loads are > possibly still executed) > > Thanks, > Dmitrij > > On 14.06.2018 16:26, Joshua Zhu wrote: > > Hi, > > > > Please review the following change. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 > > Webrev: http://cr.openjdk.java.net/~zyao/8205004/ > > > > This bug causes three failures in Jtreg ArraysEqCmpTest. > > test ArraysEqCmpTest.testArray(byte[]) test > > ArraysEqCmpTest.testArray(unsigned byte[]) test > > ArraysEqCmpTest.testArray(char[]) > > > > Array length needs to be compared for short arrays. > > Please see detailed description in JBS. > > > > Best Regards, > > Joshua > > From adinn at redhat.com Fri Jun 15 07:54:18 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Jun 2018 08:54:18 +0100 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: <0f4b1cea-56e2-d71e-f775-c8ab1426dd83@redhat.com> References: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> <0f4b1cea-56e2-d71e-f775-c8ab1426dd83@redhat.com> Message-ID: On 14/06/18 20:37, Andrew Haley wrote: > On 06/14/2018 06:59 PM, Dave Nuechterlein wrote: >> I suspect the issue is that there are no customizations for >> xgene3/emag1 in cpu/aarch64/vm_version_aarch64.cpp.> > It certainly could be that. I doubt very much that is the problem. The only customization that affects translation of dmb;ldr;dmb to ldar is the CPU_DMB_ATOMICS feature which, when set, will to update the default value for command line option UseBarriersForVolatile to true. This is only set in one case if (_cpu == CPU_CAVIUM && (_model == 0xA1)) { if (_variant == 0) _features |= CPU_DMB_ATOMICS; . . . So, unless xgene3/emag1 is masquerading as an A1 Cavium variant 0 . . . I think a more likely cause is the recent GC changes which have buggered around with the shape of the C2 idela graphs (not for any particularly good reason). If you are really using the latest JDK11 repo tip for your build then that is certainly going to affect some volatile stores and CAS operations. I'm currently working on a patch for these but have not yet tested the ldar translation. I'll take a look and let you know if there is an obvious problem with the latter. >> Are there any guidelines or best practices on how to do an initial >> vm_version variant? What test should I run before submitting a >> patch, etc. > > As long as your processor supports proper lrar/stlr you're good. Test > it with jcstress. Make sure that UseBarriersForVolatile is off. Yes, if you explicitly set -XX:-UseBarriersForVolatile on the command line the reset in vm_version will be ignored and the translation to ldar will be attempted. If it fails in that case then it means the graph shapes for loads have changed. 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 dnuechte at amperecomputing.com Thu Jun 14 23:56:49 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Thu, 14 Jun 2018 23:56:49 +0000 Subject: [aarch64-port-dev ] nightly tests Message-ID: Ampere Computing is starting to make EMAG1 specific changes to the Aarch64 port. Before we submit any patches, we would like to start running the entire nightly test suite. Who can I contact to find out which trees and what tests I should run? Thanks for any help, Dave From stuart.monteith at linaro.org Fri Jun 15 10:24:16 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 15 Jun 2018 11:24:16 +0100 Subject: [aarch64-port-dev ] nightly tests In-Reply-To: References: Message-ID: Welcome Dave, The aarch64 port for JDK 8 is maintaned here: http://hg.openjdk.java.net/aarch64-port/jdk8u/ The current release is JDK 10 will be maintained here, until September: http://hg.openjdk.java.net/jdk-updates/jdk10u/ The main line is being developed here: http://hg.openjdk.java.net/jdk/jdk/ When JDK 11 is forked off from it at the end of the month, it will appear here: http://hg.openjdk.java.net/jdk/jdk11/ As you might have noticed, the Linaro automation runs JTreg and JCStress tests. JTreg is forced to run with C1 and C2. We also run SpecJBB2015 and Terasort for benchmarking, but in truth they serve a more useful function as a sort of system test. BR, Stuart On 15 June 2018 at 00:56, Dave Nuechterlein wrote: > Ampere Computing is starting to make EMAG1 specific changes to the Aarch64 port. Before we submit any patches, we would like to start running the entire nightly test suite. Who can I contact to find out which trees and what tests I should run? > > Thanks for any help, > Dave From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:04:02 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:04:02 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: Hi Andrew, Thank you for your suggestion. It does look better this way. The change you suggested also passed all jtreg tests in fastdebug mode. New webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.03/ Thanks, Dmitrij On 07.06.2018 14:32, Andrew Haley wrote: > On 06/06/2018 07:33 PM, Dmitrij Pochepko wrote: >> large test cycle passed. no new failures(although lots of JDK-8204331 >> failures). >> hg import > As John Rose put it, we should clean up as we go. Try this. > From aph at redhat.com Fri Jun 15 17:19:14 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Jun 2018 18:19:14 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: Hi, On 06/15/2018 06:04 PM, Dmitrij Pochepko wrote: > Thank you for your suggestion. It does look better this way. > > The change you suggested also passed all jtreg tests in fastdebug mode. > > New webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.03/ OK, cool. That looks like a maintainability improvement, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Fri Jun 15 17:29:57 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jun 2018 13:29:57 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> > http://cr.openjdk.java.net/~apetushkov/8153107/ src/hotspot/share/runtime/sharedRuntime.cpp ??? No comments. src/hotspot/cpu/arm/macroAssembler_arm.cpp ??? Looks correct. Here's my analysis: ??? The X64 version of this code does this: ??? src/hotspot/cpu/x86/macroAssembler_x86.cpp: ?? ?? // Recursive locking. ? ? ? // The object is stack-locked: markword contains stack pointer to BasicLock. ? ? ? // Locked by current thread if difference with current SP is less than one page. ? ? ? subptr(tmpReg, rsp); ? ? ? // Next instruction set ZFlag == 1 (Success) if difference is less then one page. ? ? ? andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - os::vm_page_size())) ); ? ? ? movptr(Address(boxReg, 0), tmpReg); ? ? ? if (counters != NULL) { ?? ???? cond_inc32(Assembler::equal, ExternalAddress((address)counters->fast_path_entry_count_addr())); ?? ?? } ?? ?? jmp(DONE_LABEL); ??? This code path always updates "Address(boxReg, 0)" with the ??? "tmpReg" value so the markword always gets updated with a zero ??? or non-zero value. ??? The previous AMD64 code did this: ????? L3011: #ifdef AARCH64 ????? L3012: ? intptr_t mask = ((intptr_t)3) - ((intptr_t)os::vm_page_size()); ????? L3013: ? Assembler::LogicalImmediate imm(mask, false); ????? L3014: ? mov(Rscratch, SP); ????? L3015: ? sub(Rscratch, Rmark, Rscratch); ????? L3016: ? ands(Rscratch, Rscratch, imm); ????? L3017: ? b(done, ne); // exit with failure ????? L3018: ? str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); // set to zero ????? L3019: ? b(done); ????? L3020: ????? L3021: #else ????? L3022: ? // -1- test low 2 bits ????? L3023: ? movs(Rscratch, AsmOperand(Rmark, lsl, 30)); ????? L3024: ? // -2- test (hdr - SP) if the low two bits are 0 ????? L3025: ? sub(Rscratch, Rmark, SP, eq); ????? L3026: ? movs(Rscratch, AsmOperand(Rscratch, lsr, exact_log2(os::vm_page_size())), eq); ????? L3027: ? // If still 'eq' then recursive locking OK ????? L3028: ? str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero ????? L3029: ? b(done); ????? L3030: #endif ??? For the AARCH64 version, the key bug is the "b(done, ne); // exit with failure" ??? which results in the markword not getting set to a specific value. ??? Someone mentioned that we're getting a random value here and that ??? contributes to the intermittent nature of the hang. Removing L3017 ??? so that we always set the markword makes perfect sense. ??? For the non-AARCH64 version, the key bug is a little more obscure ??? (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set to zero". ??? I don't really know ARM assembly, but I'm guessing that the 'eq' parameter ??? controls whether the store of Rscratch into "Address(Rbox, ...)" occurs or ??? not. Removing the "eq" parameter in the fix so that we always set the ??? markword makes perfect sense. So thumbs up on the fix and I can sponsor it. Please provide me with an importable changeset and I'll take care of that after confirmation that the ARM folks have tested the fix and are happy with it. Dan On 6/14/18 6:08 PM, White, Derek wrote: > Hi Andrey, > > It took me looking at the code three times, but I finally saw what you mean about condition code register. OK, looks fine to me. > > You still need a (R)eviewer?s OK and then a sponsor. > > > * Derek > > From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] > Sent: Thursday, June 14, 2018 4:55 PM > To: White, Derek > Cc: Andrew Haley ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; AArch32 Port Project > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > > External Email > Hi Derek, > > that shall be ands since it expected to leave the result in the flags register, see the cmpFastLock instruct in aarch64.ad > to my taste this version is error-prone, since it's quite hard to deduce that contract FastLock node involves writing of non 0 value into DHW of stack lock when it has failed. however I don't insist. so if everyone agrees could someone please commit. sorry, I don't have necessary status > > > Regards, > Andrey > > On Thu, Jun 14, 2018 at 9:13 PM White, Derek > wrote: > Hi Andrey, > > I like this version. > > My only suggestion is minor - the "ands" at line 3016 could be a simple "and". It causes no harm but could be confusing to a reader: > > 3016 ands(Rscratch, Rscratch, imm); > > No need to see a new webrev. > - Derek > >> -----Original Message----- >> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- >> bounces at openjdk.java.net] On Behalf Of Andrey Petushkov >> Sent: Thursday, June 14, 2018 8:25 AM >> To: Andrew Haley > >> Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- >> dev at openjdk.java.net; AArch32 Port Project > dev at openjdk.java.net> >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >> External Email >> >> Hm, strange. It displays well for me in the archives page. Anyway, I've put >> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ >> >> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > wrote: >> >>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: >>>> So then if you prefer to leave the different logic in shared code >>>> between quick and slow paths I believe the fix for cpu/arm >>>> implementation (and removal of unnecessary workaround for >> cpu/aarch64) should look like this: >>> Something awful happened to the formatting of your mail. Can you put >>> it up somewhere we can see the patch? >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 >>> F A671 >>> From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:38:52 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:38:52 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <4a80b935-932a-760b-42fc-c07eb9017b20@bell-sw.com> Message-ID: <1889671f-81e9-0769-49ef-bf161eb140fc@bell-sw.com> Hi, We should issue loads as early as possible, since it's a main bottleneck. So, adding branch before ldrw will make code a bit slower. You're right about leaving cmp(cnt2, cnt1); br(NE, DONE); in short path, because it'll be a bit faster due to late load of cnt2, which has a chance to be completed while jumping to SHORT regarding LEN_IS_ZERO removal: we must keep it. Otherwise it'll compare garbage memory later, because loaded data is shifted by lslv(tmp5, tmp4, tmp5); to remove extra data. In case of 0 length, shift will be 0, so, a memory after this particular array will be compared. Can you try patch in attachment? This one move branch after load and minimize performance impact Thanks, Dmitrij On 15.06.2018 06:50, Joshua Zhu wrote: > Hi Dmitrij, > > I saw the below comments in original codes. > 5137 // on most CPUs a2 is still "locked"(surprisingly) in ldrw and it's > 5138 // faster to perform another branch before comparing a1 and a2 > before > 5139 cmp(cnt1, elem_per_word); > 5140 br(LE, SHORT); // short or same > > and if as the comments say, I think we can move > 5141 cmpoop(a1, a2); > 5142 br(EQ, SAME); > before > 5132 cbz(a1, A_IS_NULL); > 5133 ldrw(cnt1, Address(a1, length_offset)); > 5134 cbz(a2, A_IS_NULL); > 5135 ldrw(cnt2, Address(a2, length_offset)); > > and add additional code: > cmp(cnt2, cnt1); > br(NE, DONE); > in the SHORT path just as my patch did after > 5209 bind(SHORT); > > and label LEN_IS_ZERO and its path can also be deleted like below: > bind(SHORT); > cmp(cnt2, cnt1); > br(NE, DONE); > cbz(cnt1, SAME); > > Best Regards, > Joshua > >> Hi, >> >> I think you can just move existing checks: >> >> 5148 cmp(cnt2, cnt1); >> 5149 br(NE, DONE); >> >> and >> >> 5141 cmpoop(a1, a2); >> 5142 br(EQ, SAME); >> >> before jump to short case: 5140 br(LE, SHORT); // short or same >> >> Then you don't need to add any additional code. >> >> (cmpoop(a1, a2) check should go first, because cnt1 and cnt2 loads are >> possibly still executed) >> >> Thanks, >> Dmitrij >> >> On 14.06.2018 16:26, Joshua Zhu wrote: >>> Hi, >>> >>> Please review the following change. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205004 >>> Webrev: http://cr.openjdk.java.net/~zyao/8205004/ >>> >>> This bug causes three failures in Jtreg ArraysEqCmpTest. >>> test ArraysEqCmpTest.testArray(byte[]) test >>> ArraysEqCmpTest.testArray(unsigned byte[]) test >>> ArraysEqCmpTest.testArray(char[]) >>> >>> Array length needs to be compared for short arrays. >>> Please see detailed description in JBS. >>> >>> Best Regards, >>> Joshua >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: array_eq_fix.diff Type: text/x-patch Size: 1253 bytes Desc: not available URL: From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:54:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:54:12 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204473 - AARCH64: register post-index addressing mode is not supported directly In-Reply-To: References: <49941fde-5060-ffd0-867a-33286d06d18b@redhat.com> <9d9a49a2-bf30-5db8-8273-98162d543820@redhat.com> <6d92e1a2-40a4-ecea-e098-2581400c2ec8@bell-sw.com> <69623a1a-a2ac-ed3e-ff29-7ccce0a8b9cc@bell-sw.com> Message-ID: Thank you for review! On 15.06.2018 20:19, Andrew Haley wrote: > Hi, > > On 06/15/2018 06:04 PM, Dmitrij Pochepko wrote: > >> Thank you for your suggestion. It does look better this way. >> >> The change you suggested also passed all jtreg tests in fastdebug mode. >> >> New webrev: http://cr.openjdk.java.net/~dpochepk/8204473/webrev.03/ > OK, cool. That looks like a maintainability improvement, thanks. > From dmitrij.pochepko at bell-sw.com Fri Jun 15 17:54:19 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 15 Jun 2018 20:54:19 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: Now that dependency of this patch is done(8204473 - AARCH64: register post-index addressing mode is not supported directly), is it a good time to review this one? Thanks, Dmitrij On 06.06.2018 16:43, Dmitrij Pochepko wrote: > > On 06.06.2018 15:37, Andrew Haley wrote: >> On 06/06/2018 01:30 PM, Dmitrij Pochepko wrote: >>> You can take a look here: >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l2068 >>> >>> As you can see, switch by a.getMode() has 3 cases: >>> >>> 1) "base_plus_offset" (expecting only 0 offset. This is for "base >>> register, no offset" ld/st addressing mode >>> 2) "post"- this if for immediate post-index mode >>> 3) "base_plus_offset_reg" which is treated further as register >>> post-index mode. >> Well, yes, but I can't see that being [ab]used anywhere in the existing >> source. >> >>> I'll create separate issue and patch, which will add new address mode >>> (something like: "post_reg"). And final syntax for such mode usage will >>> be ... Address(post(, )), which makes it more readable. >> Yes.? And please disallow the use of Address(reg, reg) while you're >> doing >> that. >> >>> After that I'll update this fpu ld/st optimization patch accordingly. >> OK. >> > > Please take a look at webrev.02: > http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ > > The only change is to match changes in JDK-8204473 -? AARCH64: > register post-index addressing mode is not supported directly > > 2 entries of "Address(sp, rscratch1)" is now "Address(post(sp, > rscratch1))" > > > I relaunched hotspot jtreg compiler tests as sanity with both patches. > No new failures found. > > > Thanks, > > Dmitrij > From daniel.daugherty at oracle.com Fri Jun 15 17:59:48 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jun 2018 13:59:48 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> Message-ID: <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> Andrey, I'm about to send the following changeset thru Mach5 testing: $ hg log -v -r tip changeset:?? 50592:dc9e3b56c8ab tag:???????? tip user:??????? apetushkov date:??????? Fri Jun 15 13:57:32 2018 -0400 files:?????? src/hotspot/cpu/arm/macroAssembler_arm.cpp src/hotspot/share/runtime/sharedRuntime.cpp description: 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs Summary: Always set the markword for recursive monitors in MacroAssembler::fast_lock(). Reviewed-by: aph, drwhite, dcubed I don't expect any problems, but I'm paranoid so... Dan On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~apetushkov/8153107/ > > src/hotspot/share/runtime/sharedRuntime.cpp > ??? No comments. > > src/hotspot/cpu/arm/macroAssembler_arm.cpp > ??? Looks correct. Here's my analysis: > > ??? The X64 version of this code does this: > > ??? src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > ?? ?? // Recursive locking. > ? ? ? // The object is stack-locked: markword contains stack pointer > to BasicLock. > ? ? ? // Locked by current thread if difference with current SP is > less than one page. > ? ? ? subptr(tmpReg, rsp); > ? ? ? // Next instruction set ZFlag == 1 (Success) if difference is > less then one page. > ? ? ? andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - > os::vm_page_size())) ); > ? ? ? movptr(Address(boxReg, 0), tmpReg); > ? ? ? if (counters != NULL) { > ?? ???? cond_inc32(Assembler::equal, > ExternalAddress((address)counters->fast_path_entry_count_addr())); > ?? ?? } > ?? ?? jmp(DONE_LABEL); > > ??? This code path always updates "Address(boxReg, 0)" with the > ??? "tmpReg" value so the markword always gets updated with a zero > ??? or non-zero value. > > ??? The previous AMD64 code did this: > > ????? L3011: #ifdef AARCH64 > ????? L3012: ? intptr_t mask = ((intptr_t)3) - > ((intptr_t)os::vm_page_size()); > ????? L3013: ? Assembler::LogicalImmediate imm(mask, false); > ????? L3014: ? mov(Rscratch, SP); > ????? L3015: ? sub(Rscratch, Rmark, Rscratch); > ????? L3016: ? ands(Rscratch, Rscratch, imm); > ????? L3017: ? b(done, ne); // exit with failure > ????? L3018: ? str(Rscratch, Address(Rbox, > BasicLock::displaced_header_offset_in_bytes())); // set to zero > ????? L3019: ? b(done); > ????? L3020: > ????? L3021: #else > ????? L3022: ? // -1- test low 2 bits > ????? L3023: ? movs(Rscratch, AsmOperand(Rmark, lsl, 30)); > ????? L3024: ? // -2- test (hdr - SP) if the low two bits are 0 > ????? L3025: ? sub(Rscratch, Rmark, SP, eq); > ????? L3026: ? movs(Rscratch, AsmOperand(Rscratch, lsr, > exact_log2(os::vm_page_size())), eq); > ????? L3027: ? // If still 'eq' then recursive locking OK > ????? L3028: ? str(Rscratch, Address(Rbox, > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero > ????? L3029: ? b(done); > ????? L3030: #endif > > ??? For the AARCH64 version, the key bug is the "b(done, ne); // exit > with failure" > ??? which results in the markword not getting set to a specific value. > ??? Someone mentioned that we're getting a random value here and that > ??? contributes to the intermittent nature of the hang. Removing L3017 > ??? so that we always set the markword makes perfect sense. > > ??? For the non-AARCH64 version, the key bug is a little more obscure > ??? (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set > to zero". > ??? I don't really know ARM assembly, but I'm guessing that the 'eq' > parameter > ??? controls whether the store of Rscratch into "Address(Rbox, ...)" > occurs or > ??? not. Removing the "eq" parameter in the fix so that we always set the > ??? markword makes perfect sense. > > > So thumbs up on the fix and I can sponsor it. Please provide me with an > importable changeset and I'll take care of that after confirmation that > the ARM folks have tested the fix and are happy with it. > > Dan > > > On 6/14/18 6:08 PM, White, Derek wrote: >> Hi Andrey, >> >> It took me looking at the code three times, but I finally saw what >> you mean about condition code register. OK, looks fine to me. >> >> You still need a (R)eviewer?s OK and then a sponsor. >> >> >> ?? *?? Derek >> >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] >> Sent: Thursday, June 14, 2018 4:55 PM >> To: White, Derek >> Cc: Andrew Haley ; >> hotspot-runtime-dev at openjdk.java.net; >> aarch64-port-dev at openjdk.java.net; AArch32 Port Project >> >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >> >> External Email >> Hi Derek, >> >> that shall be ands since it expected to leave the result in the flags >> register, see the cmpFastLock instruct in aarch64.ad >> to my taste this version is error-prone, since it's quite hard to >> deduce that contract FastLock node involves writing of non 0 value >> into DHW of stack lock when it has failed. however I don't insist. so >> if everyone agrees could someone please commit. sorry, I don't have >> necessary status >> >> >> Regards, >> Andrey >> >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek >> > wrote: >> Hi Andrey, >> >> I like this version. >> >> My only suggestion is minor - the "ands" at line 3016 could be a >> simple "and". It causes no harm but could be confusing to a reader: >> >> 3016?? ands(Rscratch, Rscratch, imm); >> >> No need to see a new webrev. >> - Derek >> >>> -----Original Message----- >>> From: hotspot-runtime-dev >>> [mailto:hotspot-runtime-dev- >>> bounces at openjdk.java.net] On Behalf >>> Of Andrey Petushkov >>> Sent: Thursday, June 14, 2018 8:25 AM >>> To: Andrew Haley > >>> Cc: >>> hotspot-runtime-dev at openjdk.java.net; >>> aarch64-port- >>> dev at openjdk.java.net; AArch32 Port >>> Project >> dev at openjdk.java.net> >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >>> >>> External Email >>> >>> Hm, strange. It displays well for me in the archives page. Anyway, >>> I've put >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ >>> >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley >>> > wrote: >>> >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: >>>>> So then if you prefer to leave the different logic in shared code >>>>> between quick and slow paths I believe the fix for cpu/arm >>>>> implementation (and removal of unnecessary workaround for >>> cpu/aarch64) should look like this: >>>> Something awful happened to the formatting of your mail.? Can you put >>>> it up somewhere we can see the patch? >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 >>>> F A671 >>>> > > From andrey.petushkov at gmail.com Sat Jun 16 16:11:47 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Sat, 16 Jun 2018 19:11:47 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> Message-ID: Hi Dan, Thank you for sponsorship and yes, > I don't really know ARM assembly, but I'm guessing that the 'eq' > parameter > controls whether the store of Rscratch into "Address(Rbox, ...)" > occurs or > not You guess is perfectly correct! Thanks again, Andrey On Fri, Jun 15, 2018 at 9:00 PM Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Andrey, > > I'm about to send the following changeset thru Mach5 testing: > > $ hg log -v -r tip > changeset: 50592:dc9e3b56c8ab > tag: tip > user: apetushkov > date: Fri Jun 15 13:57:32 2018 -0400 > files: src/hotspot/cpu/arm/macroAssembler_arm.cpp > src/hotspot/share/runtime/sharedRuntime.cpp > description: > 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs > Summary: Always set the markword for recursive monitors in > MacroAssembler::fast_lock(). > Reviewed-by: aph, drwhite, dcubed > > > I don't expect any problems, but I'm paranoid so... > > Dan > > > On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~apetushkov/8153107/ > > > > src/hotspot/share/runtime/sharedRuntime.cpp > > No comments. > > > > src/hotspot/cpu/arm/macroAssembler_arm.cpp > > Looks correct. Here's my analysis: > > > > The X64 version of this code does this: > > > > src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > > > // Recursive locking. > > // The object is stack-locked: markword contains stack pointer > > to BasicLock. > > // Locked by current thread if difference with current SP is > > less than one page. > > subptr(tmpReg, rsp); > > // Next instruction set ZFlag == 1 (Success) if difference is > > less then one page. > > andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - > > os::vm_page_size())) ); > > movptr(Address(boxReg, 0), tmpReg); > > if (counters != NULL) { > > cond_inc32(Assembler::equal, > > ExternalAddress((address)counters->fast_path_entry_count_addr())); > > } > > jmp(DONE_LABEL); > > > > This code path always updates "Address(boxReg, 0)" with the > > "tmpReg" value so the markword always gets updated with a zero > > or non-zero value. > > > > The previous AMD64 code did this: > > > > L3011: #ifdef AARCH64 > > L3012: intptr_t mask = ((intptr_t)3) - > > ((intptr_t)os::vm_page_size()); > > L3013: Assembler::LogicalImmediate imm(mask, false); > > L3014: mov(Rscratch, SP); > > L3015: sub(Rscratch, Rmark, Rscratch); > > L3016: ands(Rscratch, Rscratch, imm); > > L3017: b(done, ne); // exit with failure > > L3018: str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes())); // set to zero > > L3019: b(done); > > L3020: > > L3021: #else > > L3022: // -1- test low 2 bits > > L3023: movs(Rscratch, AsmOperand(Rmark, lsl, 30)); > > L3024: // -2- test (hdr - SP) if the low two bits are 0 > > L3025: sub(Rscratch, Rmark, SP, eq); > > L3026: movs(Rscratch, AsmOperand(Rscratch, lsr, > > exact_log2(os::vm_page_size())), eq); > > L3027: // If still 'eq' then recursive locking OK > > L3028: str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero > > L3029: b(done); > > L3030: #endif > > > > For the AARCH64 version, the key bug is the "b(done, ne); // exit > > with failure" > > which results in the markword not getting set to a specific value. > > Someone mentioned that we're getting a random value here and that > > contributes to the intermittent nature of the hang. Removing L3017 > > so that we always set the markword makes perfect sense. > > > > For the non-AARCH64 version, the key bug is a little more obscure > > (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set > > to zero". > > I don't really know ARM assembly, but I'm guessing that the 'eq' > > parameter > > controls whether the store of Rscratch into "Address(Rbox, ...)" > > occurs or > > not. Removing the "eq" parameter in the fix so that we always set the > > markword makes perfect sense. > > > > > > So thumbs up on the fix and I can sponsor it. Please provide me with an > > importable changeset and I'll take care of that after confirmation that > > the ARM folks have tested the fix and are happy with it. > > > > Dan > > > > > > On 6/14/18 6:08 PM, White, Derek wrote: > >> Hi Andrey, > >> > >> It took me looking at the code three times, but I finally saw what > >> you mean about condition code register. OK, looks fine to me. > >> > >> You still need a (R)eviewer?s OK and then a sponsor. > >> > >> > >> * Derek > >> > >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] > >> Sent: Thursday, June 14, 2018 4:55 PM > >> To: White, Derek > >> Cc: Andrew Haley ; > >> hotspot-runtime-dev at openjdk.java.net; > >> aarch64-port-dev at openjdk.java.net; AArch32 Port Project > >> > >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > >> > >> > >> External Email > >> Hi Derek, > >> > >> that shall be ands since it expected to leave the result in the flags > >> register, see the cmpFastLock instruct in aarch64.ad > >> to my taste this version is error-prone, since it's quite hard to > >> deduce that contract FastLock node involves writing of non 0 value > >> into DHW of stack lock when it has failed. however I don't insist. so > >> if everyone agrees could someone please commit. sorry, I don't have > >> necessary status > >> > >> > >> Regards, > >> Andrey > >> > >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek > >> > wrote: > >> Hi Andrey, > >> > >> I like this version. > >> > >> My only suggestion is minor - the "ands" at line 3016 could be a > >> simple "and". It causes no harm but could be confusing to a reader: > >> > >> 3016 ands(Rscratch, Rscratch, imm); > >> > >> No need to see a new webrev. > >> - Derek > >> > >>> -----Original Message----- > >>> From: hotspot-runtime-dev > >>> [mailto:hotspot-runtime-dev- > >>> bounces at openjdk.java.net] On Behalf > >>> Of Andrey Petushkov > >>> Sent: Thursday, June 14, 2018 8:25 AM > >>> To: Andrew Haley > > >>> Cc: > >>> hotspot-runtime-dev at openjdk.java.net hotspot-runtime-dev at openjdk.java.net>; > >>> aarch64-port- > >>> dev at openjdk.java.net; AArch32 Port > >>> Project >>> dev at openjdk.java.net> > >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > >>> > >>> External Email > >>> > >>> Hm, strange. It displays well for me in the archives page. Anyway, > >>> I've put > >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > >>> > >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > >>> > wrote: > >>> > >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > >>>>> So then if you prefer to leave the different logic in shared code > >>>>> between quick and slow paths I believe the fix for cpu/arm > >>>>> implementation (and removal of unnecessary workaround for > >>> cpu/aarch64) should look like this: > >>>> Something awful happened to the formatting of your mail. Can you put > >>>> it up somewhere we can see the patch? > >>>> > >>>> -- > >>>> Andrew Haley > >>>> Java Platform Lead Engineer > >>>> Red Hat UK Ltd. > >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > >>>> F A671 > >>>> > > > > > > From daniel.daugherty at oracle.com Sat Jun 16 20:08:49 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 16 Jun 2018 16:08:49 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> Message-ID: <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> Hi Andrey, I updated the bug report with the Mach5 results so the only thing I need now is confirmation that ARM testing went fine. So whenever you or aph or both have some ARM test results we should be good to go. In particular it would be good to verify that your test that reproduces this hang no longer reproduces the hang in some relatively high number of iterations. So if your test repros the hang in 5/100 runs, I would be happy if the hang didn't repro in a 1000 runs. Dan On 6/16/18 12:11 PM, Andrey Petushkov wrote: > Hi Dan, > > Thank you for sponsorship and yes, > > I don't really know ARM assembly, but I'm guessing that the 'eq' > > parameter > > ??? controls whether the store of Rscratch into "Address(Rbox, ...)" > > occurs or > > ??? not > You guess is perfectly correct! > > Thanks again, > Andrey > > > On Fri, Jun 15, 2018 at 9:00 PM Daniel D. Daugherty > > wrote: > > Andrey, > > I'm about to send the following changeset thru Mach5 testing: > > $ hg log -v -r tip > changeset:?? 50592:dc9e3b56c8ab > tag:???????? tip > user:??????? apetushkov > date:??????? Fri Jun 15 13:57:32 2018 -0400 > files:?????? src/hotspot/cpu/arm/macroAssembler_arm.cpp > src/hotspot/share/runtime/sharedRuntime.cpp > description: > 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 > causes hangs > Summary: Always set the markword for recursive monitors in > MacroAssembler::fast_lock(). > Reviewed-by: aph, drwhite, dcubed > > > I don't expect any problems, but I'm paranoid so... > > Dan > > > On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~apetushkov/8153107/ > > > > > src/hotspot/share/runtime/sharedRuntime.cpp > > ??? No comments. > > > > src/hotspot/cpu/arm/macroAssembler_arm.cpp > > ??? Looks correct. Here's my analysis: > > > > ??? The X64 version of this code does this: > > > > ??? src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > > > ?? ?? // Recursive locking. > > ? ? ? // The object is stack-locked: markword contains stack > pointer > > to BasicLock. > > ? ? ? // Locked by current thread if difference with current SP is > > less than one page. > > ? ? ? subptr(tmpReg, rsp); > > ? ? ? // Next instruction set ZFlag == 1 (Success) if difference is > > less then one page. > > ? ? ? andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - > > os::vm_page_size())) ); > > ? ? ? movptr(Address(boxReg, 0), tmpReg); > > ? ? ? if (counters != NULL) { > > ?? ???? cond_inc32(Assembler::equal, > > ExternalAddress((address)counters->fast_path_entry_count_addr())); > > ?? ?? } > > ?? ?? jmp(DONE_LABEL); > > > > ??? This code path always updates "Address(boxReg, 0)" with the > > ??? "tmpReg" value so the markword always gets updated with a zero > > ??? or non-zero value. > > > > ??? The previous AMD64 code did this: > > > > ????? L3011: #ifdef AARCH64 > > ????? L3012: ? intptr_t mask = ((intptr_t)3) - > > ((intptr_t)os::vm_page_size()); > > ????? L3013: ? Assembler::LogicalImmediate imm(mask, false); > > ????? L3014: ? mov(Rscratch, SP); > > ????? L3015: ? sub(Rscratch, Rmark, Rscratch); > > ????? L3016: ? ands(Rscratch, Rscratch, imm); > > ????? L3017: ? b(done, ne); // exit with failure > > ????? L3018: ? str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes())); // set to zero > > ????? L3019: ? b(done); > > ????? L3020: > > ????? L3021: #else > > ????? L3022: ? // -1- test low 2 bits > > ????? L3023: ? movs(Rscratch, AsmOperand(Rmark, lsl, 30)); > > ????? L3024: ? // -2- test (hdr - SP) if the low two bits are 0 > > ????? L3025: ? sub(Rscratch, Rmark, SP, eq); > > ????? L3026: ? movs(Rscratch, AsmOperand(Rscratch, lsr, > > exact_log2(os::vm_page_size())), eq); > > ????? L3027: ? // If still 'eq' then recursive locking OK > > ????? L3028: ? str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero > > ????? L3029: ? b(done); > > ????? L3030: #endif > > > > ??? For the AARCH64 version, the key bug is the "b(done, ne); // > exit > > with failure" > > ??? which results in the markword not getting set to a specific > value. > > ??? Someone mentioned that we're getting a random value here and > that > > ??? contributes to the intermittent nature of the hang. Removing > L3017 > > ??? so that we always set the markword makes perfect sense. > > > > ??? For the non-AARCH64 version, the key bug is a little more > obscure > > ??? (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // > set > > to zero". > > ??? I don't really know ARM assembly, but I'm guessing that the > 'eq' > > parameter > > ??? controls whether the store of Rscratch into "Address(Rbox, > ...)" > > occurs or > > ??? not. Removing the "eq" parameter in the fix so that we > always set the > > ??? markword makes perfect sense. > > > > > > So thumbs up on the fix and I can sponsor it. Please provide me > with an > > importable changeset and I'll take care of that after > confirmation that > > the ARM folks have tested the fix and are happy with it. > > > > Dan > > > > > > On 6/14/18 6:08 PM, White, Derek wrote: > >> Hi Andrey, > >> > >> It took me looking at the code three times, but I finally saw what > >> you mean about condition code register. OK, looks fine to me. > >> > >> You still need a (R)eviewer?s OK and then a sponsor. > >> > >> > >> ?? *?? Derek > >> > >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com > ] > >> Sent: Thursday, June 14, 2018 4:55 PM > >> To: White, Derek > > >> Cc: Andrew Haley >; > >> hotspot-runtime-dev at openjdk.java.net > ; > >> aarch64-port-dev at openjdk.java.net > ; AArch32 Port Project > >> > > >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive > locking > >> > >> > >> External Email > >> Hi Derek, > >> > >> that shall be ands since it expected to leave the result in the > flags > >> register, see the cmpFastLock instruct in aarch64.ad > > >> to my taste this version is error-prone, since it's quite hard to > >> deduce that contract FastLock node involves writing of non 0 value > >> into DHW of stack lock when it has failed. however I don't > insist. so > >> if everyone agrees could someone please commit. sorry, I don't > have > >> necessary status > >> > >> > >> Regards, > >> Andrey > >> > >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek > >> >> wrote: > >> Hi Andrey, > >> > >> I like this version. > >> > >> My only suggestion is minor - the "ands" at line 3016 could be a > >> simple "and". It causes no harm but could be confusing to a reader: > >> > >> 3016?? ands(Rscratch, Rscratch, imm); > >> > >> No need to see a new webrev. > >> - Derek > >> > >>> -----Original Message----- > >>> From: hotspot-runtime-dev > >>> [mailto:hotspot-runtime-dev- > > > >>> bounces at openjdk.java.net > >] On Behalf > >>> Of Andrey Petushkov > >>> Sent: Thursday, June 14, 2018 8:25 AM > >>> To: Andrew Haley >> > >>> Cc: > >>> hotspot-runtime-dev at openjdk.java.net > >; > >>> aarch64-port- > >>> dev at openjdk.java.net > >; AArch32 Port > >>> Project >>> dev at openjdk.java.net > >> > >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive > locking > >>> > >>> External Email > >>> > >>> Hm, strange. It displays well for me in the archives page. > Anyway, > >>> I've put > >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > >>> > >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > >>> >> wrote: > >>> > >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > >>>>> So then if you prefer to leave the different logic in shared > code > >>>>> between quick and slow paths I believe the fix for cpu/arm > >>>>> implementation (and removal of unnecessary workaround for > >>> cpu/aarch64) should look like this: > >>>> Something awful happened to the formatting of your mail.? Can > you put > >>>> it up somewhere we can see the patch? > >>>> > >>>> -- > >>>> Andrew Haley > >>>> Java Platform Lead Engineer > >>>> Red Hat UK Ltd. > >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > >>>> F A671 > >>>> > > > > > From ci_notify at linaro.org Sun Jun 17 00:17:32 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 17 Jun 2018 00:17:32 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1002053069.2404.1529194653021.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/166/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/13 pass: 3,191; fail: 13; error: 3; not run: 11,616 Build 1: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 2: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 3: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 4: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 5: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 6: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 7: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 8: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 9: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 11: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/13 pass: 5,674; fail: 24; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/15 pass: 5,674; fail: 23; error: 2; not run: 11,619 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/13 pass: 7,903; fail: 599; error: 23 Build 1: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 2: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 3: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 4: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 5: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 6: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 7: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 8: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 9: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 10: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 11: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 12: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 Build 13: aarch64/2018/jun/13 pass: 8,435; fail: 576; error: 15 Build 14: aarch64/2018/jun/15 pass: 8,391; fail: 621; error: 16 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/13 pass: 3,862; fail: 6; error: 4 Build 1: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 2: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 3: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 4: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 5: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 6: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 7: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 8: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 9: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 10: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 11: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 12: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 Build 13: aarch64/2018/jun/13 pass: 3,891; fail: 6; error: 2 Build 14: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/13 pass: 3,200; fail: 11; error: 3; not run: 11,616 Build 1: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 2: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 3: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 4: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 5: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 6: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 7: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 8: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/13 pass: 5,682; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/15 pass: 5,681; fail: 23; error: 2; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/13 pass: 7,892; fail: 616; error: 17 Build 1: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 2: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 3: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 4: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 5: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 6: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 7: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 8: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 9: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 10: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 11: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 12: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 Build 13: aarch64/2018/jun/13 pass: 8,423; fail: 589; error: 15 Build 14: aarch64/2018/jun/15 pass: 8,420; fail: 590; error: 19 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/13 pass: 3,861; fail: 6; error: 5 Build 1: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 2: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 3: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 4: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 5: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 6: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 7: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 8: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 9: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 10: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 11: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 12: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 Build 13: aarch64/2018/jun/13 pass: 3,892; fail: 6; error: 1 Build 14: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 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): 0.63x Relative performance: Server critical-jOPS (nc): 0.48x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.27, Server: 111.14 Client 66.27 / Client 2014-04-01 (43.00): 1.54x Server 111.14 / Server 2014-04-01 (71.00): 1.57x 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 15 days. 2018-05-14 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/133/results/ 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ 2018-06-15 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/164/results/ 2018-06-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/166/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Joshua.Zhu at arm.com Sun Jun 17 03:35:58 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Sun, 17 Jun 2018 03:35:58 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest Message-ID: Hi Dmitrij, >> and label LEN_IS_ZERO and its path can also be deleted like below: >> bind(SHORT); >> cmp(cnt2, cnt1); >> br(NE, DONE); >> cbz(cnt1, SAME); >regarding LEN_IS_ZERO removal: we must keep it. Otherwise it'll compare >garbage memory later, because loaded data is shifted by lslv(tmp5, tmp4, >tmp5); to remove extra data. In case of 0 length, shift will be 0, so, a >memory after this particular array will be compared. It will not execute the instruction you mentioned, because my added instruction cbz(cnt1, SAME); will directly goto SAME path when cnt1 is zero. (no need to goto LEN_IS_ZERO to execute another compare and branch) Best Regards, Joshua From dms at samersoff.net Sun Jun 17 17:24:28 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 17 Jun 2018 20:24:28 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: <004e53a1-621d-ed1c-13b7-572b7a362e9e@samersoff.net> Dan, On 06/14/2018 11:49 PM, Daniel D. Daugherty wrote: > On 6/10/18 12:54 PM, Dmitry Samersoff wrote: >> Hello Everybody, >> >> Please, review updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.02 > This is still very confusing. In one part of this thread, we're talking > like this is ARM only fix because X64 does things differently. In another > part of this thread, we're talking like this bug affects all platforms, > but I haven't seen failures on X64 due to this so...? Something is still > not making sense here. jfr tracing testcase uses specific pattern for test, - deep recursion. On AArch64 this case triggers assert. On x86 unextended_sp is equal to sp, in this case so no asserts is triggered. So you don't have any crashes on x86. I didn't look closely to x86 code and can't say why is this difference, so I'm OK to keep this patch for AArh64 only until we experience a problem on other platform. > The patch itself is inconsistent between platforms. Here's the key > logic line in all four platforms: > > +? bool unextended_sp_safe = (unextended_sp < thread->stack_base()); > +???????????????????????????? (unextended_sp <= thread->stack_base())); > +? bool unextended_sp_safe = (_UNEXTENDED_SP <= thread->stack_base()); > +? bool unextended_sp_safe = (unextended_sp < thread->stack_base()); > > Two platforms use '<' and two use '<='. it's better to say - this code is not consistent across platforms, I didn't touch this part of assert, just removed check of unextended_sp against sp. -Dmitry > > > Dan > > >> >> CR link: >> >> https://bugs.openjdk.java.net/browse/JDK-8203481 >> >> -Dmitry >> >> On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: >>> Hello Everybody, >>> >>> Please review small fix >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ >>> >>> CR: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8203481 >>> >>> Testing: >>> >>> jfr tests that depends to safe_for_sender functionality >>> >>> ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java >>> ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java >>> >>> fails on AARCH64. >>> >>> These tests passed after the fix. >>> >>> >> > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dms at samersoff.net Sun Jun 17 17:44:29 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 17 Jun 2018 20:44:29 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> Message-ID: <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> Hello Everybody, Third version of the fix, changes limited to AArch64 only. http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.03/ -Dmitry On 05/21/2018 04:44 PM, Dmitry Samersoff wrote: > Hello Everybody, > > Please review small fix > > http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.01/ > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8203481 > > Testing: > > jfr tests that depends to safe_for_sender functionality > > ./jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java > ./jdk/jdk/jfr/event/profiling/TestFullStackTrace.java > > fails on AARCH64. > > These tests passed after the fix. > > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From david.holmes at oracle.com Mon Jun 18 07:39:04 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jun 2018 17:39:04 +1000 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <75123f5b-667b-00b9-88c4-f202e0904860@oracle.com> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <5a15ca84-e0a8-9cac-85f5-b5cdce5a4535@redhat.com> <75123f5b-667b-00b9-88c4-f202e0904860@oracle.com> Message-ID: <41f2c5e7-45cf-79dd-3620-722c99a5f974@oracle.com> On 15/06/2018 7:02 AM, Daniel D. Daugherty wrote: > On 6/14/18 9:44 AM, Andrew Haley wrote: >> On 06/10/2018 10:05 PM, David Holmes wrote: >>> I have to admit I still can't connect all the pieces here. When we are >>> operating in frame::safe_for_sender, what has set _unextended_sp? Can >>> you walk through a complete example? I can't quite connect Andrew's >>> example to the original problem. >>> >>> It still seems to me that the current frame should have: >>> >>> sp <= unextended_sp <= stack_base() >> No.? We save SP, then remove unused stack, then call int a method. > > Where does this "remove unused stack" come from? And is that only > an ARM thing? I don't remember seeing that on X64... That's my confusion too. It seems to me this is being looked at from two different perspectives. I'm assuming that if we start with a given SP and then _add_ the extra stuff we get a new SP (logically an "extended SP" and the original SP is saved as the unextended_sp - and hence SP must be below unextended SP. But I have no real understanding of the mechanics here I'm just going off the description of unextended_sp. David > >> The address saved into the current method is the old SP, before stack >> items were removed.? This is refereed to as the "unextended_sp" in th >> eshared code, but it's actually *below* the SP when a method was >> entered. > > I can see how removing things from the stack (and incrementing SP) could > result in an SP value > saved SP value. It's the "removing things from > the stack" part that has me confused right now... > > Also, we have a terminology problem in this thread. In this: > > ??? sp <= unextended_sp <= stack_base() > > I would say that 'sp' is below (or equal) to unextended_sp and that > 'unextended_sp' is below (or equal) to stack_base(). To me "below" > is like "less than" and "above" is like "greater than". > > Dan From aph at redhat.com Mon Jun 18 08:57:13 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 09:57:13 +0100 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: On 06/06/2018 02:43 PM, Dmitrij Pochepko wrote: > Please take a look at webrev.02: > http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ > > The only change is to match changes in JDK-8204473 -? AARCH64: register > post-index addressing mode is not supported directly OK, 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 Mon Jun 18 09:19:52 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 10:19:52 +0100 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> Message-ID: On 06/17/2018 06:44 PM, Dmitry Samersoff wrote: > Third version of the fix, changes limited to AArch64 only. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.03/ I don't understand what that comment means, so no-one coming to the port has any hope. When we are running interpreted code the machine stack pointer, SP, is set low enough so that the Java expression stack can grow and shrink without ever exceeding the machine stack bounds. So, ESP >= SP. When we call out of an interpreted method, SP is incremented so that the space between SP and ESP is removed. The SP saved in the callee's frame is the SP *before* this increment. So, when we walk a stack of interpreter frames the sender's SP saved in a frame might be less than the SP at the point of call. I''m wondering if I should change this code just to save confusion, but we're very close to ramp down. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Mon Jun 18 11:28:59 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 18 Jun 2018 14:28:59 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: Message-ID: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> Hi, you're right. cbz(cnt1, SAME); is enough and LEN_IS_ZERO can be removed then. (just in case, I'm not a reviewer) Thanks, Dmitrij On 17.06.2018 06:35, Joshua Zhu wrote: > > Hi Dmitrij, > > > >> and label LEN_IS_ZERO and its path can also be deleted like below: > >>????? bind(SHORT); > >>????? cmp(cnt2, cnt1); > >>????? br(NE, DONE); > >> *cbz(cnt1, SAME);* > > >regarding LEN_IS_ZERO removal: we must keep it. Otherwise it'll compare > >garbage memory later, because loaded data is shifted by lslv(tmp5, tmp4, > >tmp5); to remove extra data. In case of 0 length, shift will be 0, so, a > >memory after this particular array will be compared. > > > It will not execute the instruction you mentioned, because my?added > instruction?cbz(cnt1, SAME);?will?directly goto SAME path when cnt1 is > zero. (no need to goto LEN_IS_ZERO to execute another compare and branch) > > Best Regards, > Joshua > From dmitrij.pochepko at bell-sw.com Mon Jun 18 11:34:44 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 18 Jun 2018 14:34:44 +0300 Subject: [aarch64-port-dev ] RFR(S): 8204353 - AARCH64: optimize FPU load and stores in macroAssembler In-Reply-To: References: <56064140-2348-acb5-1859-5ac4c9e6ee30@redhat.com> <5B17C282.6030009@bell-sw.com> Message-ID: Thank you for review! On 18.06.2018 11:57, Andrew Haley wrote: > On 06/06/2018 02:43 PM, Dmitrij Pochepko wrote: >> Please take a look at webrev.02: >> http://cr.openjdk.java.net/~dpochepk/8204353/webrev.02/ >> >> The only change is to match changes in JDK-8204473 -? AARCH64: register >> post-index addressing mode is not supported directly > OK, thanks. > From dms at samersoff.net Mon Jun 18 12:46:19 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 18 Jun 2018 15:46:19 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> Message-ID: <748399ee-0104-2fc6-dac0-47359525a8c8@samersoff.net> Andrew, I'll copy your explanation of what is happening to comments. Are you ok with the fix it self? -Dmitry On 18.06.2018 12:19, Andrew Haley wrote: > On 06/17/2018 06:44 PM, Dmitry Samersoff wrote: >> Third version of the fix, changes limited to AArch64 only. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8203481/webrev.03/ > > I don't understand what that comment means, so no-one coming to the > port has any hope. > > When we are running interpreted code the machine stack pointer, SP, is > set low enough so that the Java expression stack can grow and shrink > without ever exceeding the machine stack bounds. So, ESP >= SP. > > When we call out of an interpreted method, SP is incremented so that > the space between SP and ESP is removed. The SP saved in the callee's > frame is the SP *before* this increment. So, when we walk a stack of > interpreter frames the sender's SP saved in a frame might be less than > the SP at the point of call. > > I''m wondering if I should change this code just to save confusion, > but we're very close to ramp down. > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From aph at redhat.com Mon Jun 18 12:49:30 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 13:49:30 +0100 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <748399ee-0104-2fc6-dac0-47359525a8c8@samersoff.net> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> <748399ee-0104-2fc6-dac0-47359525a8c8@samersoff.net> Message-ID: <1ab32ad5-4e1e-6051-e419-b52fefaef357@redhat.com> On 06/18/2018 01:46 PM, Dmitry Samersoff wrote: > I'll copy your explanation of what is happening to comments. > > Are you ok with the fix it self? Sure. For AArch64 only. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Mon Jun 18 13:29:16 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 16:29:16 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> Message-ID: <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> Hi Dan, The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. Ed? Thank you, Andrey > On 16 Jun 2018, at 23:08, Daniel D. Daugherty wrote: > > Hi Andrey, > > I updated the bug report with the Mach5 results so the only thing I need > now is confirmation that ARM testing went fine. So whenever you or aph > or both have some ARM test results we should be good to go. > > In particular it would be good to verify that your test that reproduces > this hang no longer reproduces the hang in some relatively high number > of iterations. So if your test repros the hang in 5/100 runs, I would > be happy if the hang didn't repro in a 1000 runs. > > Dan > > > On 6/16/18 12:11 PM, Andrey Petushkov wrote: >> Hi Dan, >> >> Thank you for sponsorship and yes, >> > I don't really know ARM assembly, but I'm guessing that the 'eq' >> > parameter >> > controls whether the store of Rscratch into "Address(Rbox, ...)" >> > occurs or >> > not >> You guess is perfectly correct! >> >> Thanks again, >> Andrey >> >> >> On Fri, Jun 15, 2018 at 9:00 PM Daniel D. Daugherty > wrote: >> Andrey, >> >> I'm about to send the following changeset thru Mach5 testing: >> >> $ hg log -v -r tip >> changeset: 50592:dc9e3b56c8ab >> tag: tip >> user: apetushkov >> date: Fri Jun 15 13:57:32 2018 -0400 >> files: src/hotspot/cpu/arm/macroAssembler_arm.cpp >> src/hotspot/share/runtime/sharedRuntime.cpp >> description: >> 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs >> Summary: Always set the markword for recursive monitors in >> MacroAssembler::fast_lock(). >> Reviewed-by: aph, drwhite, dcubed >> >> >> I don't expect any problems, but I'm paranoid so... >> >> Dan >> >> >> On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: >> > > http://cr.openjdk.java.net/~apetushkov/8153107/ >> > >> > src/hotspot/share/runtime/sharedRuntime.cpp >> > No comments. >> > >> > src/hotspot/cpu/arm/macroAssembler_arm.cpp >> > Looks correct. Here's my analysis: >> > >> > The X64 version of this code does this: >> > >> > src/hotspot/cpu/x86/macroAssembler_x86.cpp: >> > >> > // Recursive locking. >> > // The object is stack-locked: markword contains stack pointer >> > to BasicLock. >> > // Locked by current thread if difference with current SP is >> > less than one page. >> > subptr(tmpReg, rsp); >> > // Next instruction set ZFlag == 1 (Success) if difference is >> > less then one page. >> > andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - >> > os::vm_page_size())) ); >> > movptr(Address(boxReg, 0), tmpReg); >> > if (counters != NULL) { >> > cond_inc32(Assembler::equal, >> > ExternalAddress((address)counters->fast_path_entry_count_addr())); >> > } >> > jmp(DONE_LABEL); >> > >> > This code path always updates "Address(boxReg, 0)" with the >> > "tmpReg" value so the markword always gets updated with a zero >> > or non-zero value. >> > >> > The previous AMD64 code did this: >> > >> > L3011: #ifdef AARCH64 >> > L3012: intptr_t mask = ((intptr_t)3) - >> > ((intptr_t)os::vm_page_size()); >> > L3013: Assembler::LogicalImmediate imm(mask, false); >> > L3014: mov(Rscratch, SP); >> > L3015: sub(Rscratch, Rmark, Rscratch); >> > L3016: ands(Rscratch, Rscratch, imm); >> > L3017: b(done, ne); // exit with failure >> > L3018: str(Rscratch, Address(Rbox, >> > BasicLock::displaced_header_offset_in_bytes())); // set to zero >> > L3019: b(done); >> > L3020: >> > L3021: #else >> > L3022: // -1- test low 2 bits >> > L3023: movs(Rscratch, AsmOperand(Rmark, lsl, 30)); >> > L3024: // -2- test (hdr - SP) if the low two bits are 0 >> > L3025: sub(Rscratch, Rmark, SP, eq); >> > L3026: movs(Rscratch, AsmOperand(Rscratch, lsr, >> > exact_log2(os::vm_page_size())), eq); >> > L3027: // If still 'eq' then recursive locking OK >> > L3028: str(Rscratch, Address(Rbox, >> > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero >> > L3029: b(done); >> > L3030: #endif >> > >> > For the AARCH64 version, the key bug is the "b(done, ne); // exit >> > with failure" >> > which results in the markword not getting set to a specific value. >> > Someone mentioned that we're getting a random value here and that >> > contributes to the intermittent nature of the hang. Removing L3017 >> > so that we always set the markword makes perfect sense. >> > >> > For the non-AARCH64 version, the key bug is a little more obscure >> > (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set >> > to zero". >> > I don't really know ARM assembly, but I'm guessing that the 'eq' >> > parameter >> > controls whether the store of Rscratch into "Address(Rbox, ...)" >> > occurs or >> > not. Removing the "eq" parameter in the fix so that we always set the >> > markword makes perfect sense. >> > >> > >> > So thumbs up on the fix and I can sponsor it. Please provide me with an >> > importable changeset and I'll take care of that after confirmation that >> > the ARM folks have tested the fix and are happy with it. >> > >> > Dan >> > >> > >> > On 6/14/18 6:08 PM, White, Derek wrote: >> >> Hi Andrey, >> >> >> >> It took me looking at the code three times, but I finally saw what >> >> you mean about condition code register. OK, looks fine to me. >> >> >> >> You still need a (R)eviewer?s OK and then a sponsor. >> >> >> >> >> >> * Derek >> >> >> >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com ] >> >> Sent: Thursday, June 14, 2018 4:55 PM >> >> To: White, Derek > >> >> Cc: Andrew Haley >; >> >> hotspot-runtime-dev at openjdk.java.net ; >> >> aarch64-port-dev at openjdk.java.net ; AArch32 Port Project >> >> > >> >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >> >> >> >> >> External Email >> >> Hi Derek, >> >> >> >> that shall be ands since it expected to leave the result in the flags >> >> register, see the cmpFastLock instruct in aarch64.ad > >> >> to my taste this version is error-prone, since it's quite hard to >> >> deduce that contract FastLock node involves writing of non 0 value >> >> into DHW of stack lock when it has failed. however I don't insist. so >> >> if everyone agrees could someone please commit. sorry, I don't have >> >> necessary status >> >> >> >> >> >> Regards, >> >> Andrey >> >> >> >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek >> >> >> wrote: >> >> Hi Andrey, >> >> >> >> I like this version. >> >> >> >> My only suggestion is minor - the "ands" at line 3016 could be a >> >> simple "and". It causes no harm but could be confusing to a reader: >> >> >> >> 3016 ands(Rscratch, Rscratch, imm); >> >> >> >> No need to see a new webrev. >> >> - Derek >> >> >> >>> -----Original Message----- >> >>> From: hotspot-runtime-dev >> >>> [mailto:hotspot-runtime-dev- > >> >>> bounces at openjdk.java.net >] On Behalf >> >>> Of Andrey Petushkov >> >>> Sent: Thursday, June 14, 2018 8:25 AM >> >>> To: Andrew Haley >> >> >>> Cc: >> >>> hotspot-runtime-dev at openjdk.java.net >; >> >>> aarch64-port- >> >>> dev at openjdk.java.net >; AArch32 Port >> >>> Project > >>> dev at openjdk.java.net >> >> >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >>> >> >>> External Email >> >>> >> >>> Hm, strange. It displays well for me in the archives page. Anyway, >> >>> I've put >> >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ >> >>> >> >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley >> >>> >> wrote: >> >>> >> >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: >> >>>>> So then if you prefer to leave the different logic in shared code >> >>>>> between quick and slow paths I believe the fix for cpu/arm >> >>>>> implementation (and removal of unnecessary workaround for >> >>> cpu/aarch64) should look like this: >> >>>> Something awful happened to the formatting of your mail. Can you put >> >>>> it up somewhere we can see the patch? >> >>>> >> >>>> -- >> >>>> Andrew Haley >> >>>> Java Platform Lead Engineer >> >>>> Red Hat UK Ltd. > >> >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 >> >>>> >F A671 >> >>>> >> > >> > >> > From aph at redhat.com Mon Jun 18 13:39:14 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 14:39:14 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> Message-ID: On 06/18/2018 02:29 PM, Andrey Petushkov wrote: > The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. > Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. > Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. Where is the problem? We're asking you to test it on AArch32. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Mon Jun 18 13:43:21 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 16:43:21 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> Message-ID: <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> > On 18 Jun 2018, at 16:39, Andrew Haley wrote: > > On 06/18/2018 02:29 PM, Andrey Petushkov wrote: >> The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. >> Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. >> Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. > > Where is the problem? We're asking you to test it on AArch32. Please elaborate what meaning you put into ?AArch32? term here - The patch under review deals with cpu/arm implementation. I do not have a reproducer for binaries created from this code - I do have a reproducer for the cpu/aarch32 and I?ve tested extremely similar patch numerous times. Does it count as a means of verification of patch under review? > > -- > 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 Jun 18 13:47:25 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 14:47:25 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> Message-ID: <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> On 06/18/2018 02:43 PM, Andrey Petushkov wrote: > >> On 18 Jun 2018, at 16:39, Andrew Haley wrote: >> >> On 06/18/2018 02:29 PM, Andrey Petushkov wrote: >>> The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. >>> Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. >>> Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. >> >> Where is the problem? We're asking you to test it on AArch32. > Please elaborate what meaning you put into ?AArch32? term here > > - The patch under review deals with cpu/arm implementation. I do not have a reproducer for binaries created from this code > - I do have a reproducer for the cpu/aarch32 and I?ve tested extremely similar patch numerous times. Does it count as a means of verification of patch under review? Ah, my mistake. This patch also affects AArch64. So, I take it that your problem is that you don't have AArch64 systems to run the test on? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dnuechte at amperecomputing.com Mon Jun 18 13:55:27 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Mon, 18 Jun 2018 13:55:27 +0000 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: References: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> <0f4b1cea-56e2-d71e-f775-c8ab1426dd83@redhat.com> Message-ID: I am new to all of this. Is there some way to track the progress on this fix? Can I help? I have a very simple JMH test that exposes this. Would that be helpful? Sorry for all of the questions. Dave -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Friday, June 15, 2018 1:54 AM To: Andrew Haley ; Dave Nuechterlein ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] barrier use in JDK11 On 14/06/18 20:37, Andrew Haley wrote: > On 06/14/2018 06:59 PM, Dave Nuechterlein wrote: >> I suspect the issue is that there are no customizations for >> xgene3/emag1 in cpu/aarch64/vm_version_aarch64.cpp.> > It certainly could be that. I doubt very much that is the problem. The only customization that affects translation of dmb;ldr;dmb to ldar is the CPU_DMB_ATOMICS feature which, when set, will to update the default value for command line option UseBarriersForVolatile to true. This is only set in one case if (_cpu == CPU_CAVIUM && (_model == 0xA1)) { if (_variant == 0) _features |= CPU_DMB_ATOMICS; . . . So, unless xgene3/emag1 is masquerading as an A1 Cavium variant 0 . . . I think a more likely cause is the recent GC changes which have buggered around with the shape of the C2 idela graphs (not for any particularly good reason). If you are really using the latest JDK11 repo tip for your build then that is certainly going to affect some volatile stores and CAS operations. I'm currently working on a patch for these but have not yet tested the ldar translation. I'll take a look and let you know if there is an obvious problem with the latter. >> Are there any guidelines or best practices on how to do an initial >> vm_version variant? What test should I run before submitting a >> patch, etc. > > As long as your processor supports proper lrar/stlr you're good. Test > it with jcstress. Make sure that UseBarriersForVolatile is off. Yes, if you explicitly set -XX:-UseBarriersForVolatile on the command line the reset in vm_version will be ignored and the translation to ldar will be attempted. If it fails in that case then it means the graph shapes for loads have changed. 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 dnuechte at amperecomputing.com Mon Jun 18 14:02:47 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Mon, 18 Jun 2018 14:02:47 +0000 Subject: [aarch64-port-dev ] nightly regressions Message-ID: Ampere Computing would like to start the process of having our hardware added to the nightly AArch64 release testing. Who do we talk with to start this process? How many machines are required? Thanks, Dave From andrey.petushkov at gmail.com Mon Jun 18 14:09:47 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 17:09:47 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> Message-ID: <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> I can, but that would only be check for regression, not the fix itself > On 18 Jun 2018, at 16:47, Andrew Haley wrote: > > On 06/18/2018 02:43 PM, Andrey Petushkov wrote: >> >>> On 18 Jun 2018, at 16:39, Andrew Haley wrote: >>> >>> On 06/18/2018 02:29 PM, Andrey Petushkov wrote: >>>> The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. >>>> Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. >>>> Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. >>> >>> Where is the problem? We're asking you to test it on AArch32. >> Please elaborate what meaning you put into ?AArch32? term here >> >> - The patch under review deals with cpu/arm implementation. I do not have a reproducer for binaries created from this code >> - I do have a reproducer for the cpu/aarch32 and I?ve tested extremely similar patch numerous times. Does it count as a means of verification of patch under review? > > Ah, my mistake. This patch also affects AArch64. So, I take it that > your problem is that you don't have AArch64 systems to run the test on? > > -- > 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 Mon Jun 18 14:20:32 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 18 Jun 2018 17:20:32 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <1ab32ad5-4e1e-6051-e419-b52fefaef357@redhat.com> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> <748399ee-0104-2fc6-dac0-47359525a8c8@samersoff.net> <1ab32ad5-4e1e-6051-e419-b52fefaef357@redhat.com> Message-ID: Comments changed in-place. On 18.06.2018 15:49, Andrew Haley wrote: > On 06/18/2018 01:46 PM, Dmitry Samersoff wrote: >> I'll copy your explanation of what is happening to comments. >> >> Are you ok with the fix it self? > > Sure. For AArch64 only. > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From aph at redhat.com Mon Jun 18 15:37:10 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 16:37:10 +0100 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: References: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> <0f4b1cea-56e2-d71e-f775-c8ab1426dd83@redhat.com> Message-ID: <9a9d10b5-5f23-d37a-0ff4-ffc66071a5ad@redhat.com> On 06/18/2018 02:55 PM, Dave Nuechterlein wrote: > I am new to all of this. Is there some way to track the progress on this fix? Can I help? > > I have a very simple JMH test that exposes this. Would that be helpful? Not really, because we don't know what it does on *your* hardware. We need you to run the tests with the option -XX:UseBarriersForVolatile -- 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 Jun 18 15:42:07 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 16:42:07 +0100 Subject: [aarch64-port-dev ] barrier use in JDK11 In-Reply-To: <9a9d10b5-5f23-d37a-0ff4-ffc66071a5ad@redhat.com> References: <53428199-6a38-ead0-d69a-e71995476f88@redhat.com> <0f4b1cea-56e2-d71e-f775-c8ab1426dd83@redhat.com> <9a9d10b5-5f23-d37a-0ff4-ffc66071a5ad@redhat.com> Message-ID: <2e637055-796f-34f4-d385-f086d7d14dcb@redhat.com> On 06/18/2018 04:37 PM, Andrew Haley wrote: > On 06/18/2018 02:55 PM, Dave Nuechterlein wrote: >> I am new to all of this. Is there some way to track the progress on this fix? Can I help? >> >> I have a very simple JMH test that exposes this. Would that be helpful? > > Not really, because we don't know what it does on *your* hardware. > > We need you to run the tests with the option -XX:UseBarriersForVolatile > -XX:+UseBarriersForVolatile -- 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 Jun 18 15:46:43 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 16:46:43 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> Message-ID: <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> On 06/18/2018 03:09 PM, Andrey Petushkov wrote: > I can, but that would only be check for regression, not the fix itself I do not understand. Do you mean that out have no reproducer at all? Not even this one? http://cr.openjdk.java.net/~aph/RecursiveLocking.java -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Mon Jun 18 16:02:58 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 19:02:58 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> Message-ID: > On 18 Jun 2018, at 18:46, Andrew Haley wrote: > > On 06/18/2018 03:09 PM, Andrey Petushkov wrote: >> I can, but that would only be check for regression, not the fix itself > > I do not understand. Do you mean that out have no reproducer > at all? Not even this one? > > http://cr.openjdk.java.net/~aph/RecursiveLocking.java This one does not work for me. In additional it?s quite hard to catch such problem using this code - it does not end any of the threads, hence you cannot rely on deadlock detection mechanism to find out whether any stale locks left. Apparently something should be quite well hand-crafted to put enough 0-s to the stack prior to creation of the stack lock there And as I said, I have a reproducer. It just happen that it only reproduces the problem on port-aarch32 implementation > > -- > 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 Jun 18 16:07:14 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 17:07:14 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> Message-ID: <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > And as I said, I have a reproducer. It just happen that it only reproduces the problem on port-aarch32 implementation Well, I'm sure that I can't reproduce the problem either, and I believe that the bug does not exist on AArch64. I'm happy for your patch to be committed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Mon Jun 18 18:34:21 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Jun 2018 14:34:21 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> Message-ID: <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Greetings, OK so I'm not going to get a "go" based on reproducible test results. I'm okay with that as long as I get a "go" from the other folks reviewing and discussing this change: Andrew Haley???? - go (as stated below) Andrey Petushkov - Dan Daugherty??? - go (since Oracle platform testing passed) Derek White????? - Of course, I could have listed Andrey as a go since he is the author of the fix, but I didn't want to assume... :-) Dan On 6/18/18 12:07 PM, Andrew Haley wrote: > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >> And as I said, I have a reproducer. It just happen that it only reproduces the problem on port-aarch32 implementation > Well, I'm sure that I can't reproduce the problem either, and > I believe that the bug does not exist on AArch64. I'm happy for > your patch to be committed. > From dmitrij.pochepko at bell-sw.com Mon Jun 18 18:53:14 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 18 Jun 2018 21:53:14 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> Message-ID: <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> Hi, I added lots of documentation in a same manner as in Math::sin/cos patch. Please take a look at updated webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.05/ Thanks, Dmitrij On 04.06.2018 18:50, Dmitrij Pochepko wrote: > On 04.06.2018 16:09, Dmitrij Pochepko wrote: >> On 04.06.2018 15:53, Andrew Haley wrote: >>> On 06/03/2018 03:03 PM, Dmitry Samersoff wrote: >>>> This version of the fix looks good to me. >>> Note: the same applies to log as cost and sin.? Please make sure that >>> the intrinsic is used for interp, C1, and C2. >>> >> Yes. Sin/cos change to enable intrinsics in intrp and C1 do it for >> all math intrinsics. I'm currently testing it > Please take a look at updated webrev. The only change is move log stub > generation call from generate_all() to generate_initial(). It will be > required for interpreter to use initialized stub routine address after > JDK-8204289 is pushed > > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.04/ > > Thanks, > Dmitrij > > From Derek.White at cavium.com Mon Jun 18 19:53:44 2018 From: Derek.White at cavium.com (White, Derek) Date: Mon, 18 Jun 2018 19:53:44 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Yes, It's a go for me on aarch64. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty > Sent: Monday, June 18, 2018 2:34 PM > To: Andrew Haley ; Andrey Petushkov > > Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; AArch32 Port Project dev at openjdk.java.net> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > External Email > > Greetings, > > OK so I'm not going to get a "go" based on reproducible test results. > I'm okay with that as long as I get a "go" from the other folks reviewing and > discussing this change: > > Andrew Haley - go (as stated below) > Andrey Petushkov - > Dan Daugherty - go (since Oracle platform testing passed) > Derek White - > > Of course, I could have listed Andrey as a go since he is the author of the fix, > but I didn't want to assume... :-) > > Dan > > > On 6/18/18 12:07 PM, Andrew Haley wrote: > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > >> And as I said, I have a reproducer. It just happen that it only > >> reproduces the problem on port-aarch32 implementation > > Well, I'm sure that I can't reproduce the problem either, and I > > believe that the bug does not exist on AArch64. I'm happy for your > > patch to be committed. > > From andrey.petushkov at gmail.com Mon Jun 18 20:04:09 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 23:04:09 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Sure, me too Thank you, Andrey On Mon, Jun 18, 2018, 22:53 White, Derek wrote: > Yes, It's a go for me on aarch64. > > - Derek > > > -----Original Message----- > > From: aarch64-port-dev [mailto:aarch64-port-dev- > > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty > > Sent: Monday, June 18, 2018 2:34 PM > > To: Andrew Haley ; Andrey Petushkov > > > > Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- > > dev at openjdk.java.net; AArch32 Port Project > dev at openjdk.java.net> > > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > > > External Email > > > > Greetings, > > > > OK so I'm not going to get a "go" based on reproducible test results. > > I'm okay with that as long as I get a "go" from the other folks > reviewing and > > discussing this change: > > > > Andrew Haley - go (as stated below) > > Andrey Petushkov - > > Dan Daugherty - go (since Oracle platform testing passed) > > Derek White - > > > > Of course, I could have listed Andrey as a go since he is the author of > the fix, > > but I didn't want to assume... :-) > > > > Dan > > > > > > On 6/18/18 12:07 PM, Andrew Haley wrote: > > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > > >> And as I said, I have a reproducer. It just happen that it only > > >> reproduces the problem on port-aarch32 implementation > > > Well, I'm sure that I can't reproduce the problem either, and I > > > believe that the bug does not exist on AArch64. I'm happy for your > > > patch to be committed. > > > > > From daniel.daugherty at oracle.com Mon Jun 18 20:31:19 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Jun 2018 16:31:19 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Thanks Derek and Andrey! aleksei.voitylov at bell-sw.com sent me mail letting me know that boris.ulasevich at bell-sw.com is doing some testing on the change on ARM32 and will let me know the results tomorrow. Dan On 6/18/18 4:04 PM, Andrey Petushkov wrote: > Sure, me too > > Thank you, > Andrey > > On Mon, Jun 18, 2018, 22:53 White, Derek > wrote: > > Yes, It's a go for me on aarch64. > > ?- Derek > > > -----Original Message----- > > From: aarch64-port-dev [mailto:aarch64-port-dev- > > > bounces at openjdk.java.net ] On > Behalf Of Daniel D. Daugherty > > Sent: Monday, June 18, 2018 2:34 PM > > To: Andrew Haley >; > Andrey Petushkov > > > > > Cc: aarch64-port-dev at openjdk.java.net > ; hotspot-runtime- > > dev at openjdk.java.net ; AArch32 Port > Project > dev at openjdk.java.net > > > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive > locking > > > > External Email > > > > Greetings, > > > > OK so I'm not going to get a "go" based on reproducible test > results. > > I'm okay with that as long as I get a "go" from the other folks > reviewing and > > discussing this change: > > > > Andrew Haley? ? ?- go (as stated below) > > Andrey Petushkov - > > Dan Daugherty? ? - go (since Oracle platform testing passed) > > Derek White? ? ? - > > > > Of course, I could have listed Andrey as a go since he is the > author of the fix, > > but I didn't want to assume... :-) > > > > Dan > > > > > > On 6/18/18 12:07 PM, Andrew Haley wrote: > > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > > >> And as I said, I have a reproducer. It just happen that it only > > >> reproduces the problem on port-aarch32 implementation > > > Well, I'm sure that I can't reproduce the problem either, and I > > > believe that the bug does not exist on AArch64. I'm happy for your > > > patch to be committed. > > > > From ci_notify at linaro.org Tue Jun 19 00:19:49 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 19 Jun 2018 00:19:49 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1409570723.2681.1529367590392.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/168/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/15 pass: 3,234; fail: 34; error: 4; not run: 11,619 Build 1: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 2: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 3: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 4: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 5: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 6: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 7: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 8: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 10: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/13 pass: 5,674; fail: 24; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/15 pass: 5,674; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/17 pass: 5,698; fail: 23; error: 2; not run: 11,619 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/15 pass: 7,865; fail: 629; error: 32 Build 1: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 2: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 3: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 4: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 5: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 6: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 7: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 8: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 9: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 10: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 11: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 Build 12: aarch64/2018/jun/13 pass: 8,435; fail: 576; error: 15 Build 13: aarch64/2018/jun/15 pass: 8,391; fail: 621; error: 16 Build 14: aarch64/2018/jun/17 pass: 8,423; fail: 594; error: 16 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/15 pass: 3,863; fail: 6; error: 3 Build 1: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 2: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 3: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 4: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 5: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 6: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 7: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 8: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 9: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 10: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 11: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 Build 12: aarch64/2018/jun/13 pass: 3,891; fail: 6; error: 2 Build 13: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 14: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/15 pass: 3,243; fail: 33; error: 3; not run: 11,619 Build 1: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 2: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 3: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 4: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 5: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 6: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 7: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 8: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 11: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/13 pass: 5,682; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/15 pass: 5,681; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/17 pass: 5,705; fail: 22; error: 3; not run: 11,619 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/15 pass: 7,918; fail: 586; error: 22 Build 1: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 2: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 3: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 4: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 5: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 6: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 7: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 8: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 9: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 10: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 11: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 Build 12: aarch64/2018/jun/13 pass: 8,423; fail: 589; error: 15 Build 13: aarch64/2018/jun/15 pass: 8,420; fail: 590; error: 19 Build 14: aarch64/2018/jun/17 pass: 8,436; fail: 581; error: 17 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/15 pass: 3,858; fail: 6; error: 8 Build 1: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 2: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 3: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 4: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 5: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 6: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 7: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 8: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 9: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 10: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 11: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 Build 12: aarch64/2018/jun/13 pass: 3,892; fail: 6; error: 1 Build 13: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 14: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 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): 0.63x Relative performance: Server critical-jOPS (nc): 0.55x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 65.35, Server: 110.27 Client 65.35 / Client 2014-04-01 (43.00): 1.52x Server 110.27 / Server 2014-04-01 (71.00): 1.55x 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 15 days. 2018-05-16 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/135/results/ 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ 2018-06-15 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/164/results/ 2018-06-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/166/results/ 2018-06-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/168/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From andrey.petushkov at gmail.com Tue Jun 19 10:26:48 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Tue, 19 Jun 2018 13:26:48 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Ah, I see. Looks like Bell-sw is the only company besides Oracle which works with arm(32) port (at least in the open) so it make sense for them to make their testing Thanks for letting me know Regards, Andrey On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Thanks Derek and Andrey! > > aleksei.voitylov at bell-sw.com sent me mail letting me know that > boris.ulasevich at bell-sw.com is doing some testing on the change > on ARM32 and will let me know the results tomorrow. > > Dan > > > On 6/18/18 4:04 PM, Andrey Petushkov wrote: > > Sure, me too > > Thank you, > Andrey > > On Mon, Jun 18, 2018, 22:53 White, Derek wrote: > >> Yes, It's a go for me on aarch64. >> >> - Derek >> >> > -----Original Message----- >> > From: aarch64-port-dev [mailto:aarch64-port-dev- >> > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >> > Sent: Monday, June 18, 2018 2:34 PM >> > To: Andrew Haley ; Andrey Petushkov >> > >> > Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >> > dev at openjdk.java.net; AArch32 Port Project > > dev at openjdk.java.net> >> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> > >> > External Email >> > >> > Greetings, >> > >> > OK so I'm not going to get a "go" based on reproducible test results. >> > I'm okay with that as long as I get a "go" from the other folks >> reviewing and >> > discussing this change: >> > >> > Andrew Haley - go (as stated below) >> > Andrey Petushkov - >> > Dan Daugherty - go (since Oracle platform testing passed) >> > Derek White - >> > >> > Of course, I could have listed Andrey as a go since he is the author of >> the fix, >> > but I didn't want to assume... :-) >> > >> > Dan >> > >> > >> > On 6/18/18 12:07 PM, Andrew Haley wrote: >> > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >> > >> And as I said, I have a reproducer. It just happen that it only >> > >> reproduces the problem on port-aarch32 implementation >> > > Well, I'm sure that I can't reproduce the problem either, and I >> > > believe that the bug does not exist on AArch64. I'm happy for your >> > > patch to be committed. >> > > >> >> > From Joshua.Zhu at arm.com Tue Jun 19 10:27:21 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Tue, 19 Jun 2018 10:27:21 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> Message-ID: Thanks Dmitrij! I update webrev at http://cr.openjdk.java.net/~zyao/8205004/webrev.02/ with LEN_IS_ZERO removal. Hi, you're right. cbz(cnt1, SAME); is enough and LEN_IS_ZERO can be removed then. (just in case, I'm not a reviewer) Thanks, Dmitrij On 17.06.2018 06:35, Joshua Zhu wrote: Hi Dmitrij, >> and label LEN_IS_ZERO and its path can also be deleted like below: >> bind(SHORT); >> cmp(cnt2, cnt1); >> br(NE, DONE); >> cbz(cnt1, SAME); >regarding LEN_IS_ZERO removal: we must keep it. Otherwise it'll compare >garbage memory later, because loaded data is shifted by lslv(tmp5, tmp4, >tmp5); to remove extra data. In case of 0 length, shift will be 0, so, a >memory after this particular array will be compared. It will not execute the instruction you mentioned, because my added instruction cbz(cnt1, SAME); will directly goto SAME path when cnt1 is zero. (no need to goto LEN_IS_ZERO to execute another compare and branch) Best Regards, Joshua From dmitrij.pochepko at bell-sw.com Tue Jun 19 12:17:44 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 19 Jun 2018 15:17:44 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> Message-ID: <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> Hi, this one looks good for me. Let's wait for official reviewer to approve it and then I'll be happy to push it. (Sorry you had to cleanup my code). Thanks, Dmitrij On 19.06.2018 13:27, Joshua Zhu wrote: > > Thanks Dmitrij! > > I update webrev at > > http://cr.openjdk.java.net/~zyao/8205004/webrev.02/ > > > with LEN_IS_ZERO removal. > > Hi, > > you're right. cbz(cnt1, SAME); is enough and LEN_IS_ZERO can be > removed then. > > (just in case, I'm not a reviewer) > > Thanks, > > Dmitrij > > On 17.06.2018 06:35, Joshua Zhu wrote: > > Hi Dmitrij, > > >> and label LEN_IS_ZERO and its path can also be deleted like below: > >>????? bind(SHORT); > >>????? cmp(cnt2, cnt1); > >>????? br(NE, DONE); > >> *cbz(cnt1, SAME);* > > >regarding LEN_IS_ZERO removal: we must keep it. Otherwise it'll > compare > >garbage memory later, because loaded data is shifted by > lslv(tmp5, tmp4, > >tmp5); to remove extra data. In case of 0 length, shift will be > 0, so, a > >memory after this particular array will be compared. > > It will not execute the instruction you mentioned, because > my?added instruction?cbz(cnt1, SAME);?will?directly goto SAME path > when cnt1 is zero. (no need to goto LEN_IS_ZERO to execute another > compare and branch) > > Best Regards, > > Joshua > From aph at redhat.com Tue Jun 19 12:47:55 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 13:47:55 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> Message-ID: <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> On 06/19/2018 01:17 PM, Dmitrij Pochepko wrote: > this one looks good for me. Let's wait for official reviewer to approve > it and then I'll be happy to push it. OK, but cmpoop isn't right here: use a straight compare. When Shenandoah goes in we'll have a write barrier on the dest anyway. No need to ask for approval with that change. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Tue Jun 19 14:40:29 2018 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 19 Jun 2018 17:40:29 +0300 Subject: [aarch64-port-dev ] [11] RFR(XS): 8205341: AARCH64: Clean up duplicate uzp1 & uzp2 instruction definition Message-ID: Hello, Please review a small fix for aarch64 instructions encoding. The fix removes duplicate definition of two instructions from assembler_aarch64.hpp. The only usage of that variant was in MacroAssembler::kernel_crc32 in case of -UseCRC32 +UseNeon. I changed it to use another definition and made testing comparing checksums for that case. rfe: https://bugs.openjdk.java.net/browse/JDK-8205341 webrev: http://cr.openjdk.java.net/~dchuyko/8205341/webrev.00/ -Dmitry From sbergman at redhat.com Tue Jun 19 15:44:48 2018 From: sbergman at redhat.com (Stephan Bergmann) Date: Tue, 19 Jun 2018 17:44:48 +0200 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 Message-ID: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> I unfortunately have a bit of a complex set up, but maybe somebody has an idea how to debug this further: I am doing Flatpak builds of LibreOffice. Those builds used to use OpenJDK 9. When I tried to switch to OpenJDK 10, builds for aarch64 started to fail, in one of LibreOffice's tests that instantiates a JVM in a (C++) process. Builds for other platforms (arm 32-bit, x86 32- and 64-bit) did not fail. I unsuccessfully tried to reproduce the failure on various aarch64 machines (with varying 4K and 64K PAGE_SIZE); the only kind of machine I could reproduce it on (not fully reliably, but around 50% of the time) is massively parallel 64-core machines (which are routinely used for those Flatpak builds). The symptom is always a SIGSEGV in a thread whose gdb backtrace shows just a single frame of apparently JIT-generated code (i.e., outside any .so). A typical such case is > (gdb) disas 0x0000ffff8a1d6d80,+300 > Dump of assembler code from 0xffff8a1d6d80 to 0xffff8a1d6eac: > 0x0000ffff8a1d6d80: .inst 0xffffffff ; undefined > 0x0000ffff8a1d6d84: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6d88: adrp x12, 0x100003add7000 > 0x0000ffff8a1d6d8c: .inst 0x00386024 ; NYI > 0x0000ffff8a1d6d90: .inst 0x60806000 ; undefined > 0x0000ffff8a1d6d94: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6d98: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6d9c: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6da0: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6da4: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6da8: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6dac: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6db0: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6db4: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6db8: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6dbc: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6dc0: ldr w8, [x1,#8] > 0x0000ffff8a1d6dc4: cmp w9, w8 > 0x0000ffff8a1d6dc8: b.eq 0xffff8a1d6e00 > 0x0000ffff8a1d6dcc: adrp x8, 0xffff8263c000 > 0x0000ffff8a1d6dd0: add x8, x8, #0x700 > 0x0000ffff8a1d6dd4: br x8 > 0x0000ffff8a1d6dd8: nop > 0x0000ffff8a1d6ddc: nop > 0x0000ffff8a1d6de0: nop > 0x0000ffff8a1d6de4: nop > 0x0000ffff8a1d6de8: nop > 0x0000ffff8a1d6dec: nop > 0x0000ffff8a1d6df0: nop > 0x0000ffff8a1d6df4: nop > 0x0000ffff8a1d6df8: nop > 0x0000ffff8a1d6dfc: nop > 0x0000ffff8a1d6e00: nop > 0x0000ffff8a1d6e04: sub x9, sp, #0x14, lsl #12 > 0x0000ffff8a1d6e08: str xzr, [x9] > 0x0000ffff8a1d6e0c: sub sp, sp, #0x40 > 0x0000ffff8a1d6e10: stp x29, x30, [sp,#48] > 0x0000ffff8a1d6e14: ldr w0, [x1,#28] > 0x0000ffff8a1d6e18: ldp x29, x30, [sp,#48] > 0x0000ffff8a1d6e1c: add sp, sp, #0x40 > 0x0000ffff8a1d6e20: ldr x8, [x28,#112] > => 0x0000ffff8a1d6e24: ldr wzr, [x8] > 0x0000ffff8a1d6e28: ret > 0x0000ffff8a1d6e2c: nop > 0x0000ffff8a1d6e30: nop > 0x0000ffff8a1d6e34: ldr x0, [x28,#736] > 0x0000ffff8a1d6e38: str xzr, [x28,#736] > 0x0000ffff8a1d6e3c: str xzr, [x28,#744] > 0x0000ffff8a1d6e40: ldp x29, x30, [sp,#48] > 0x0000ffff8a1d6e44: add sp, sp, #0x40 > 0x0000ffff8a1d6e48: adrp x8, 0xffff8266e000 > 0x0000ffff8a1d6e4c: add x8, x8, #0x200 > 0x0000ffff8a1d6e50: br x8 > 0x0000ffff8a1d6e54: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e58: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e5c: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e60: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e64: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e68: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e6c: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e70: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e74: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e78: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e7c: .inst 0x00000000 ; undefined > 0x0000ffff8a1d6e80: adrp x8, 0xffff82670000 > 0x0000ffff8a1d6e84: add x8, x8, #0x900 > 0x0000ffff8a1d6e88: blr x8 > 0x0000ffff8a1d6e8c: stp x0, x1, [sp,#-256]! > 0x0000ffff8a1d6e90: stp x2, x3, [sp,#16] > 0x0000ffff8a1d6e94: stp x4, x5, [sp,#32] > 0x0000ffff8a1d6e98: stp x6, x7, [sp,#48] > 0x0000ffff8a1d6e9c: stp x8, x9, [sp,#64] > 0x0000ffff8a1d6ea0: stp x10, x11, [sp,#80] > 0x0000ffff8a1d6ea4: stp x12, x13, [sp,#96] > 0x0000ffff8a1d6ea8: stp x14, x15, [sp,#112] > End of assembler dump. where x8 points at no memory (0xffff99d52008 in this case). The details of the code differ across crashes, but it appears to always be a "ldr wzr, [x8]" that triggers the SIGSEGV. There are more than 100 threads, most of which appear to be JVM housekeeping ones (compilation, gc; I have lengthy gdb "thread apply all backtrace full" output that I could provide.) I could no longer reproduce the failure when I either made LibreOffice instantiate the in-process JVM with -Xint to force interpreted mode, or built OpenJDK with --with-debug-level=fastdebug instead of --with-debug-level=release. (I tried a handful of times each; but as the failure isn't reliably reproducible, that might of course also have just been luck.) The OpenJDK in the Flatpak build environment is http://hg.openjdk.java.net/jdk-updates/jdk10u tag jdk-10.0.1+10 (at , which in turn uses the sources packaged by ). I also tried replacing that with current tip of that branch, but that didn't make a difference (it felt like the failure happened less often, like only 10% of the time, but again, that might just have been luck). I have only restricted access to that 64-core machine, and the only viable way for me to test the issue is via the Flatpak build environment (e.g., I cannot easily download another OpenJDK 10 build to test against). The failing LibreOffice test itself is also somewhat complex, and it would likely not be easy to strip it down to a small reproducer. Thoughts, anyone? From aph at redhat.com Tue Jun 19 16:15:22 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 17:15:22 +0100 Subject: [aarch64-port-dev ] [11] RFR(XS): 8205341: AARCH64: Clean up duplicate uzp1 & uzp2 instruction definition In-Reply-To: References: Message-ID: <372c7fc7-3434-e1ee-29ca-b77052235e77@redhat.com> On 06/19/2018 03:40 PM, Dmitry Chuyko wrote: > rfe: https://bugs.openjdk.java.net/browse/JDK-8205341 > webrev: http://cr.openjdk.java.net/~dchuyko/8205341/webrev.00/ That looks right. 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 Tue Jun 19 16:19:35 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 17:19:35 +0100 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> Message-ID: On 06/19/2018 04:44 PM, Stephan Bergmann wrote: > I unfortunately have a bit of a complex set up, but maybe somebody has > an idea how to debug this further: > > I am doing Flatpak builds of LibreOffice. Those builds used to use > OpenJDK 9. When I tried to switch to OpenJDK 10, builds for aarch64 > started to fail, in one of LibreOffice's tests that instantiates a JVM > in a (C++) process. Builds for other platforms (arm 32-bit, x86 32- and > 64-bit) did not fail. > > I unsuccessfully tried to reproduce the failure on various aarch64 > machines (with varying 4K and 64K PAGE_SIZE); the only kind of machine I > could reproduce it on (not fully reliably, but around 50% of the time) > is massively parallel 64-core machines (which are routinely used for > those Flatpak builds). > > The symptom is always a SIGSEGV in a thread whose gdb backtrace shows > just a single frame of apparently JIT-generated code (i.e., outside any > .so). A typical such case is > >> (gdb) disas 0x0000ffff8a1d6d80,+300 >> Dump of assembler code from 0xffff8a1d6d80 to 0xffff8a1d6eac: >> 0x0000ffff8a1d6d80: .inst 0xffffffff ; undefined >> 0x0000ffff8a1d6d84: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6d88: adrp x12, 0x100003add7000 >> 0x0000ffff8a1d6d8c: .inst 0x00386024 ; NYI >> 0x0000ffff8a1d6d90: .inst 0x60806000 ; undefined >> 0x0000ffff8a1d6d94: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6d98: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6d9c: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6da0: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6da4: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6da8: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6dac: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6db0: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6db4: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6db8: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6dbc: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6dc0: ldr w8, [x1,#8] >> 0x0000ffff8a1d6dc4: cmp w9, w8 >> 0x0000ffff8a1d6dc8: b.eq 0xffff8a1d6e00 >> 0x0000ffff8a1d6dcc: adrp x8, 0xffff8263c000 >> 0x0000ffff8a1d6dd0: add x8, x8, #0x700 >> 0x0000ffff8a1d6dd4: br x8 >> 0x0000ffff8a1d6dd8: nop >> 0x0000ffff8a1d6ddc: nop >> 0x0000ffff8a1d6de0: nop >> 0x0000ffff8a1d6de4: nop >> 0x0000ffff8a1d6de8: nop >> 0x0000ffff8a1d6dec: nop >> 0x0000ffff8a1d6df0: nop >> 0x0000ffff8a1d6df4: nop >> 0x0000ffff8a1d6df8: nop >> 0x0000ffff8a1d6dfc: nop >> 0x0000ffff8a1d6e00: nop >> 0x0000ffff8a1d6e04: sub x9, sp, #0x14, lsl #12 >> 0x0000ffff8a1d6e08: str xzr, [x9] >> 0x0000ffff8a1d6e0c: sub sp, sp, #0x40 >> 0x0000ffff8a1d6e10: stp x29, x30, [sp,#48] >> 0x0000ffff8a1d6e14: ldr w0, [x1,#28] >> 0x0000ffff8a1d6e18: ldp x29, x30, [sp,#48] >> 0x0000ffff8a1d6e1c: add sp, sp, #0x40 >> 0x0000ffff8a1d6e20: ldr x8, [x28,#112] >> => 0x0000ffff8a1d6e24: ldr wzr, [x8] >> 0x0000ffff8a1d6e28: ret >> 0x0000ffff8a1d6e2c: nop >> 0x0000ffff8a1d6e30: nop >> 0x0000ffff8a1d6e34: ldr x0, [x28,#736] >> 0x0000ffff8a1d6e38: str xzr, [x28,#736] >> 0x0000ffff8a1d6e3c: str xzr, [x28,#744] >> 0x0000ffff8a1d6e40: ldp x29, x30, [sp,#48] >> 0x0000ffff8a1d6e44: add sp, sp, #0x40 >> 0x0000ffff8a1d6e48: adrp x8, 0xffff8266e000 >> 0x0000ffff8a1d6e4c: add x8, x8, #0x200 >> 0x0000ffff8a1d6e50: br x8 >> 0x0000ffff8a1d6e54: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e58: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e5c: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e60: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e64: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e68: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e6c: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e70: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e74: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e78: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e7c: .inst 0x00000000 ; undefined >> 0x0000ffff8a1d6e80: adrp x8, 0xffff82670000 >> 0x0000ffff8a1d6e84: add x8, x8, #0x900 >> 0x0000ffff8a1d6e88: blr x8 >> 0x0000ffff8a1d6e8c: stp x0, x1, [sp,#-256]! >> 0x0000ffff8a1d6e90: stp x2, x3, [sp,#16] >> 0x0000ffff8a1d6e94: stp x4, x5, [sp,#32] >> 0x0000ffff8a1d6e98: stp x6, x7, [sp,#48] >> 0x0000ffff8a1d6e9c: stp x8, x9, [sp,#64] >> 0x0000ffff8a1d6ea0: stp x10, x11, [sp,#80] >> 0x0000ffff8a1d6ea4: stp x12, x13, [sp,#96] >> 0x0000ffff8a1d6ea8: stp x14, x15, [sp,#112] >> End of assembler dump. > > where x8 points at no memory (0xffff99d52008 in this case). The details > of the code differ across crashes, but it appears to always be a "ldr > wzr, [x8]" that triggers the SIGSEGV. There are more than 100 threads, > most of which appear to be JVM housekeeping ones (compilation, gc; I > have lengthy gdb "thread apply all backtrace full" output that I could > provide.) That's a safepoint SEGV. It's deliberate. If you step at that point you'll enter the safepoint code. > I could no longer reproduce the failure when I either made LibreOffice > instantiate the in-process JVM with -Xint to force interpreted mode, or > built OpenJDK with --with-debug-level=fastdebug instead of > --with-debug-level=release. (I tried a handful of times each; but as > the failure isn't reliably reproducible, that might of course also have > just been luck.) > > The OpenJDK in the Flatpak build environment is > http://hg.openjdk.java.net/jdk-updates/jdk10u tag jdk-10.0.1+10 (at > , > which in turn uses the sources packaged by > ). I > also tried replacing that with current tip of that branch, but that > didn't make a difference (it felt like the failure happened less often, > like only 10% of the time, but again, that might just have been luck). > > I have only restricted access to that 64-core machine, and the only > viable way for me to test the issue is via the Flatpak build environment > (e.g., I cannot easily download another OpenJDK 10 build to test > against). The failing LibreOffice test itself is also somewhat complex, > and it would likely not be easy to strip it down to a small reproducer. > > Thoughts, anyone? What exactly is the failure? You should have an error message and an error log file. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From boris.ulasevich at bell-sw.com Tue Jun 19 17:30:45 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 19 Jun 2018 20:30:45 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> Hi all, I ran the test in different modes (single/multiple run, debug/release, Xcomp/mixed), but I can NOT reproduce the issue with current ARM32 jdk-jdk trunk. The test works Ok, as well as other jtreg runtime tests I have run today - both with and without the change. The change itself looks reasonable. Andrey, I think you can commit it, and I will take care of the issue if something will go wrong. best regards, Boris On 19.06.2018 13:26, Andrey Petushkov wrote: > Ah, I see. Looks like Bell-sw is the only company besides Oracle which > works with arm(32) port (at least in the open) so it make sense for them to > make their testing > > Thanks for letting me know > > Regards, > Andrey > > On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > >> Thanks Derek and Andrey! >> >> aleksei.voitylov at bell-sw.com sent me mail letting me know that >> boris.ulasevich at bell-sw.com is doing some testing on the change >> on ARM32 and will let me know the results tomorrow. >> >> Dan >> >> >> On 6/18/18 4:04 PM, Andrey Petushkov wrote: >> >> Sure, me too >> >> Thank you, >> Andrey >> >> On Mon, Jun 18, 2018, 22:53 White, Derek wrote: >> >>> Yes, It's a go for me on aarch64. >>> >>> - Derek >>> >>>> -----Original Message----- >>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>> bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >>>> Sent: Monday, June 18, 2018 2:34 PM >>>> To: Andrew Haley ; Andrey Petushkov >>>> >>>> Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net; AArch32 Port Project >>> dev at openjdk.java.net> >>>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >>>> >>>> External Email >>>> >>>> Greetings, >>>> >>>> OK so I'm not going to get a "go" based on reproducible test results. >>>> I'm okay with that as long as I get a "go" from the other folks >>> reviewing and >>>> discussing this change: >>>> >>>> Andrew Haley - go (as stated below) >>>> Andrey Petushkov - >>>> Dan Daugherty - go (since Oracle platform testing passed) >>>> Derek White - >>>> >>>> Of course, I could have listed Andrey as a go since he is the author of >>> the fix, >>>> but I didn't want to assume... :-) >>>> >>>> Dan >>>> >>>> >>>> On 6/18/18 12:07 PM, Andrew Haley wrote: >>>>> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >>>>>> And as I said, I have a reproducer. It just happen that it only >>>>>> reproduces the problem on port-aarch32 implementation >>>>> Well, I'm sure that I can't reproduce the problem either, and I >>>>> believe that the bug does not exist on AArch64. I'm happy for your >>>>> patch to be committed. >>>>> >>> >>> >> From daniel.daugherty at oracle.com Tue Jun 19 17:32:43 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jun 2018 13:32:43 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> Message-ID: Boris, Thanks for the testing and, based on what you wrote below, I will add you as a reviewer. I'll take care of pushing the fix shortly. Dan On 6/19/18 1:30 PM, Boris Ulasevich wrote: > Hi all, > > ? I ran the test in different modes (single/multiple run, > debug/release, Xcomp/mixed), but I can NOT reproduce the issue with > current ARM32 jdk-jdk trunk. The test works Ok, as well as other jtreg > runtime tests I have run today - both with and without the change. > > ? The change itself looks reasonable. Andrey, I think you can commit > it, and I will take care of the issue if something will go wrong. > > best regards, > Boris > > > On 19.06.2018 13:26, Andrey Petushkov wrote: >> Ah, I see. Looks like Bell-sw is the only company besides Oracle which >> works with arm(32) port (at least in the open) so it make sense for >> them to >> make their testing >> >> Thanks for letting me know >> >> Regards, >> Andrey >> >> On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < >> daniel.daugherty at oracle.com> wrote: >> >>> Thanks Derek and Andrey! >>> >>> aleksei.voitylov at bell-sw.com sent me mail letting me know that >>> boris.ulasevich at bell-sw.com is doing some testing on the change >>> on ARM32 and will let me know the results tomorrow. >>> >>> Dan >>> >>> >>> On 6/18/18 4:04 PM, Andrey Petushkov wrote: >>> >>> Sure,? me too >>> >>> Thank you, >>> Andrey >>> >>> On Mon, Jun 18, 2018, 22:53 White, Derek >>> wrote: >>> >>>> Yes, It's a go for me on aarch64. >>>> >>>> ? - Derek >>>> >>>>> -----Original Message----- >>>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>>> bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >>>>> Sent: Monday, June 18, 2018 2:34 PM >>>>> To: Andrew Haley ; Andrey Petushkov >>>>> >>>>> Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net; AArch32 Port Project >>>> dev at openjdk.java.net> >>>>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive >>>>> locking >>>>> >>>>> External Email >>>>> >>>>> Greetings, >>>>> >>>>> OK so I'm not going to get a "go" based on reproducible test results. >>>>> I'm okay with that as long as I get a "go" from the other folks >>>> reviewing and >>>>> discussing this change: >>>>> >>>>> Andrew Haley???? - go (as stated below) >>>>> Andrey Petushkov - >>>>> Dan Daugherty??? - go (since Oracle platform testing passed) >>>>> Derek White????? - >>>>> >>>>> Of course, I could have listed Andrey as a go since he is the >>>>> author of >>>> the fix, >>>>> but I didn't want to assume... :-) >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 6/18/18 12:07 PM, Andrew Haley wrote: >>>>>> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >>>>>>> And as I said, I have a reproducer. It just happen that it only >>>>>>> reproduces the problem on port-aarch32 implementation >>>>>> Well, I'm sure that I can't reproduce the problem either, and I >>>>>> believe that the bug does not exist on AArch64.? I'm happy for your >>>>>> patch to be committed. >>>>>> >>>> >>>> >>> From daniel.daugherty at oracle.com Tue Jun 19 17:42:08 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jun 2018 13:42:08 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> Message-ID: Pushed the following changeset: $ hg log -v -r tip changeset:?? 50666:3e66d204af9b tag:???????? tip user:??????? apetushkov date:??????? Fri Jun 15 13:57:32 2018 -0400 files:?????? src/hotspot/cpu/arm/macroAssembler_arm.cpp src/hotspot/share/runtime/sharedRuntime.cpp description: 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs Summary: Always set the markword for recursive monitors in MacroAssembler::fast_lock(). Reviewed-by: aph, drwhite, dcubed, bulasevich Andrey, thanks for fixing this (longstanding) bug! Dan On 6/19/18 1:32 PM, Daniel D. Daugherty wrote: > Boris, > > Thanks for the testing and, based on what you wrote below, I will add > you as a reviewer. > > I'll take care of pushing the fix shortly. > > Dan > > > On 6/19/18 1:30 PM, Boris Ulasevich wrote: >> Hi all, >> >> ? I ran the test in different modes (single/multiple run, >> debug/release, Xcomp/mixed), but I can NOT reproduce the issue with >> current ARM32 jdk-jdk trunk. The test works Ok, as well as other >> jtreg runtime tests I have run today - both with and without the change. >> >> ? The change itself looks reasonable. Andrey, I think you can commit >> it, and I will take care of the issue if something will go wrong. >> >> best regards, >> Boris >> >> >> On 19.06.2018 13:26, Andrey Petushkov wrote: >>> Ah, I see. Looks like Bell-sw is the only company besides Oracle which >>> works with arm(32) port (at least in the open) so it make sense for >>> them to >>> make their testing >>> >>> Thanks for letting me know >>> >>> Regards, >>> Andrey >>> >>> On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < >>> daniel.daugherty at oracle.com> wrote: >>> >>>> Thanks Derek and Andrey! >>>> >>>> aleksei.voitylov at bell-sw.com sent me mail letting me know that >>>> boris.ulasevich at bell-sw.com is doing some testing on the change >>>> on ARM32 and will let me know the results tomorrow. >>>> >>>> Dan >>>> >>>> >>>> On 6/18/18 4:04 PM, Andrey Petushkov wrote: >>>> >>>> Sure,? me too >>>> >>>> Thank you, >>>> Andrey >>>> >>>> On Mon, Jun 18, 2018, 22:53 White, Derek >>>> wrote: >>>> >>>>> Yes, It's a go for me on aarch64. >>>>> >>>>> ? - Derek >>>>> >>>>>> -----Original Message----- >>>>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>>>> bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >>>>>> Sent: Monday, June 18, 2018 2:34 PM >>>>>> To: Andrew Haley ; Andrey Petushkov >>>>>> >>>>>> Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net; AArch32 Port Project >>>>> dev at openjdk.java.net> >>>>>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive >>>>>> locking >>>>>> >>>>>> External Email >>>>>> >>>>>> Greetings, >>>>>> >>>>>> OK so I'm not going to get a "go" based on reproducible test >>>>>> results. >>>>>> I'm okay with that as long as I get a "go" from the other folks >>>>> reviewing and >>>>>> discussing this change: >>>>>> >>>>>> Andrew Haley???? - go (as stated below) >>>>>> Andrey Petushkov - >>>>>> Dan Daugherty??? - go (since Oracle platform testing passed) >>>>>> Derek White????? - >>>>>> >>>>>> Of course, I could have listed Andrey as a go since he is the >>>>>> author of >>>>> the fix, >>>>>> but I didn't want to assume... :-) >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 6/18/18 12:07 PM, Andrew Haley wrote: >>>>>>> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >>>>>>>> And as I said, I have a reproducer. It just happen that it only >>>>>>>> reproduces the problem on port-aarch32 implementation >>>>>>> Well, I'm sure that I can't reproduce the problem either, and I >>>>>>> believe that the bug does not exist on AArch64.? I'm happy for your >>>>>>> patch to be committed. >>>>>>> >>>>> >>>>> >>>> > > From aph at redhat.com Tue Jun 19 18:02:02 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jun 2018 19:02:02 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> Message-ID: <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> On 06/18/2018 07:53 PM, Dmitrij Pochepko wrote: > I added lots of documentation in a same manner as in Math::sin/cos patch. > > Please take a look at updated webrev: > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.05/ Very nice! Same review comments as sin/cos. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Derek.White at cavium.com Tue Jun 19 23:45:06 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 19 Jun 2018 23:45:06 +0000 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> Message-ID: Hi Dmitrij, I have a few questions and comments, mostly because my FP knowledge is so rusty. src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp: - Line 68: Could align to 64 bytes. We're going to load the first 64 bytes, may as well use one cache line. - Lines 71, 77, 79. You could comment these lines with "_coeff", "_log2", and "_L_tbl", for clearer correspondence to x86 code. - Line 204: I believe that we should be looking for equal to 0.0: 204 // if (X = 0.0d) return -INFINITY; - The (float)(zeroExponent(X) code was fun. - Are there any concerns about denormalized inputs? I didn't see any obvious problem in the code pulling aaprt and adding in exponents, but there's nothing obvious in that code to me. - The RETURN_MINF_OR_NAN block can generate a wide range of signaling and non-signaling NaNs. I forget how signaling Nans are treated in the Java math mode - are they just treated as quiet NaNs or are they never supposed to appear? Looks good otherwise! - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Tuesday, June 19, 2018 2:02 PM > To: Dmitrij Pochepko > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic > for Math.log > > On 06/18/2018 07:53 PM, Dmitrij Pochepko wrote: > > I added lots of documentation in a same manner as in Math::sin/cos patch. > > > > Please take a look at updated webrev: > > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.05/ > > Very nice! Same review comments as sin/cos. Thanks. From sbergman at redhat.com Wed Jun 20 06:16:51 2018 From: sbergman at redhat.com (Stephan Bergmann) Date: Wed, 20 Jun 2018 08:16:51 +0200 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> Message-ID: <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> On 19/06/18 18:19, Andrew Haley wrote: > On 06/19/2018 04:44 PM, Stephan Bergmann wrote: >> I unfortunately have a bit of a complex set up, but maybe somebody has >> an idea how to debug this further: >> >> I am doing Flatpak builds of LibreOffice. Those builds used to use >> OpenJDK 9. When I tried to switch to OpenJDK 10, builds for aarch64 >> started to fail, in one of LibreOffice's tests that instantiates a JVM >> in a (C++) process. Builds for other platforms (arm 32-bit, x86 32- and >> 64-bit) did not fail. >> >> I unsuccessfully tried to reproduce the failure on various aarch64 >> machines (with varying 4K and 64K PAGE_SIZE); the only kind of machine I >> could reproduce it on (not fully reliably, but around 50% of the time) >> is massively parallel 64-core machines (which are routinely used for >> those Flatpak builds). >> >> The symptom is always a SIGSEGV in a thread whose gdb backtrace shows >> just a single frame of apparently JIT-generated code (i.e., outside any >> .so). A typical such case is >> >>> (gdb) disas 0x0000ffff8a1d6d80,+300 >>> Dump of assembler code from 0xffff8a1d6d80 to 0xffff8a1d6eac: >>> 0x0000ffff8a1d6d80: .inst 0xffffffff ; undefined >>> 0x0000ffff8a1d6d84: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6d88: adrp x12, 0x100003add7000 >>> 0x0000ffff8a1d6d8c: .inst 0x00386024 ; NYI >>> 0x0000ffff8a1d6d90: .inst 0x60806000 ; undefined >>> 0x0000ffff8a1d6d94: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6d98: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6d9c: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6da0: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6da4: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6da8: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6dac: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6db0: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6db4: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6db8: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6dbc: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6dc0: ldr w8, [x1,#8] >>> 0x0000ffff8a1d6dc4: cmp w9, w8 >>> 0x0000ffff8a1d6dc8: b.eq 0xffff8a1d6e00 >>> 0x0000ffff8a1d6dcc: adrp x8, 0xffff8263c000 >>> 0x0000ffff8a1d6dd0: add x8, x8, #0x700 >>> 0x0000ffff8a1d6dd4: br x8 >>> 0x0000ffff8a1d6dd8: nop >>> 0x0000ffff8a1d6ddc: nop >>> 0x0000ffff8a1d6de0: nop >>> 0x0000ffff8a1d6de4: nop >>> 0x0000ffff8a1d6de8: nop >>> 0x0000ffff8a1d6dec: nop >>> 0x0000ffff8a1d6df0: nop >>> 0x0000ffff8a1d6df4: nop >>> 0x0000ffff8a1d6df8: nop >>> 0x0000ffff8a1d6dfc: nop >>> 0x0000ffff8a1d6e00: nop >>> 0x0000ffff8a1d6e04: sub x9, sp, #0x14, lsl #12 >>> 0x0000ffff8a1d6e08: str xzr, [x9] >>> 0x0000ffff8a1d6e0c: sub sp, sp, #0x40 >>> 0x0000ffff8a1d6e10: stp x29, x30, [sp,#48] >>> 0x0000ffff8a1d6e14: ldr w0, [x1,#28] >>> 0x0000ffff8a1d6e18: ldp x29, x30, [sp,#48] >>> 0x0000ffff8a1d6e1c: add sp, sp, #0x40 >>> 0x0000ffff8a1d6e20: ldr x8, [x28,#112] >>> => 0x0000ffff8a1d6e24: ldr wzr, [x8] >>> 0x0000ffff8a1d6e28: ret >>> 0x0000ffff8a1d6e2c: nop >>> 0x0000ffff8a1d6e30: nop >>> 0x0000ffff8a1d6e34: ldr x0, [x28,#736] >>> 0x0000ffff8a1d6e38: str xzr, [x28,#736] >>> 0x0000ffff8a1d6e3c: str xzr, [x28,#744] >>> 0x0000ffff8a1d6e40: ldp x29, x30, [sp,#48] >>> 0x0000ffff8a1d6e44: add sp, sp, #0x40 >>> 0x0000ffff8a1d6e48: adrp x8, 0xffff8266e000 >>> 0x0000ffff8a1d6e4c: add x8, x8, #0x200 >>> 0x0000ffff8a1d6e50: br x8 >>> 0x0000ffff8a1d6e54: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e58: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e5c: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e60: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e64: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e68: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e6c: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e70: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e74: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e78: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e7c: .inst 0x00000000 ; undefined >>> 0x0000ffff8a1d6e80: adrp x8, 0xffff82670000 >>> 0x0000ffff8a1d6e84: add x8, x8, #0x900 >>> 0x0000ffff8a1d6e88: blr x8 >>> 0x0000ffff8a1d6e8c: stp x0, x1, [sp,#-256]! >>> 0x0000ffff8a1d6e90: stp x2, x3, [sp,#16] >>> 0x0000ffff8a1d6e94: stp x4, x5, [sp,#32] >>> 0x0000ffff8a1d6e98: stp x6, x7, [sp,#48] >>> 0x0000ffff8a1d6e9c: stp x8, x9, [sp,#64] >>> 0x0000ffff8a1d6ea0: stp x10, x11, [sp,#80] >>> 0x0000ffff8a1d6ea4: stp x12, x13, [sp,#96] >>> 0x0000ffff8a1d6ea8: stp x14, x15, [sp,#112] >>> End of assembler dump. >> >> where x8 points at no memory (0xffff99d52008 in this case). The details >> of the code differ across crashes, but it appears to always be a "ldr >> wzr, [x8]" that triggers the SIGSEGV. There are more than 100 threads, >> most of which appear to be JVM housekeeping ones (compilation, gc; I >> have lengthy gdb "thread apply all backtrace full" output that I could >> provide.) > > That's a safepoint SEGV. It's deliberate. If you step at that > point you'll enter the safepoint code. > >> I could no longer reproduce the failure when I either made LibreOffice >> instantiate the in-process JVM with -Xint to force interpreted mode, or >> built OpenJDK with --with-debug-level=fastdebug instead of >> --with-debug-level=release. (I tried a handful of times each; but as >> the failure isn't reliably reproducible, that might of course also have >> just been luck.) >> >> The OpenJDK in the Flatpak build environment is >> http://hg.openjdk.java.net/jdk-updates/jdk10u tag jdk-10.0.1+10 (at >> , >> which in turn uses the sources packaged by >> ). I >> also tried replacing that with current tip of that branch, but that >> didn't make a difference (it felt like the failure happened less often, >> like only 10% of the time, but again, that might just have been luck). >> >> I have only restricted access to that 64-core machine, and the only >> viable way for me to test the issue is via the Flatpak build environment >> (e.g., I cannot easily download another OpenJDK 10 build to test >> against). The failing LibreOffice test itself is also somewhat complex, >> and it would likely not be easy to strip it down to a small reproducer. >> >> Thoughts, anyone? > > What exactly is the failure? The failure is that the process (running a C++ cppunittester executable, with an in-process instantiated JVM) terminates due to a SIGSEGV. When inspecting the generated core file with gdb, it claims the above thread caused that "fatal" SIGSEGV. > You should have an error message and an error log file. There is no stdout/-err output from the JVM (only some routine cppunittester output). And I cannot find any log file (you mean one of those .hs-err-pid* files or whatever they are called exactly, right?). Where should I look for it ($HOME, cwd, ...)? From shade at redhat.com Wed Jun 20 06:27:04 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Jun 2018 08:27:04 +0200 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> Message-ID: On 06/20/2018 08:16 AM, Stephan Bergmann wrote: >> That's a safepoint SEGV.? It's deliberate.? If you step at that >> point you'll enter the safepoint code. ... >> What exactly is the failure? > > The failure is that the process (running a C++ cppunittester executable, with an in-process > instantiated JVM) terminates due to a SIGSEGV.? When inspecting the generated core file with gdb, it > claims the above thread caused that "fatal" SIGSEGV. My first bet would be that cpuunittester had installed its own signal handlers that overwrote JVM's SEGV handlers that are required for normal operation. You would need to use jsig to make JVM work in that config, see: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html -Aleksey From Joshua.Zhu at arm.com Wed Jun 20 07:26:28 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Wed, 20 Jun 2018 07:26:28 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> Message-ID: Hi Andrew, Thanks for your review! I think you are saying read barrier in ShenandoahBarrierSetAssembler::obj_equals() implementation. Therefore I wonder why here we should directly compare these two oop instead of cmpoop. And see current MacroAssembler::arrays_equals(), cmpoop is already used for compare in same scenario. Hence I think cmpoop(a1, a2) should also be applied here for short path? Best Regards, Joshua > -----Original Message----- > From: Andrew Haley > Sent: Tuesday, June 19, 2018 8:48 PM > > On 06/19/2018 01:17 PM, Dmitrij Pochepko wrote: > > this one looks good for me. Let's wait for official reviewer to > > approve it and then I'll be happy to push it. > > OK, but cmpoop isn't right here: use a straight compare. When Shenandoah > goes in we'll have a write barrier on the dest anyway. > No need to ask for approval with that change. > > -- > 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 Wed Jun 20 08:05:47 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2018 09:05:47 +0100 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> Message-ID: On 06/20/2018 07:27 AM, Aleksey Shipilev wrote: > On 06/20/2018 08:16 AM, Stephan Bergmann wrote: >>> That's a safepoint SEGV. It's deliberate. If you step at that >>> point you'll enter the safepoint code. > > ... > >>> What exactly is the failure? >> >> The failure is that the process (running a C++ cppunittester executable, with an in-process >> instantiated JVM) terminates due to a SIGSEGV. When inspecting the generated core file with gdb, it >> claims the above thread caused that "fatal" SIGSEGV. > > My first bet would be that cpuunittester had installed its own > signal handlers that overwrote JVM's SEGV handlers that are required > for normal operation. You would need to use jsig to make JVM work in > that config, see: > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html That sounds plausible, but it doesn't explain why switching from 9 to 10 causes a problem: we always use SEGV for safepoints. Still, it's worth a try. -- 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 Wed Jun 20 08:16:29 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2018 09:16:29 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> Message-ID: <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> On 06/20/2018 08:26 AM, Joshua Zhu wrote: > I think you are saying read barrier in > ShenandoahBarrierSetAssembler::obj_equals() implementation. > Therefore I wonder why here we should directly compare these two oop > instead of cmpoop. Yes. > And see current MacroAssembler::arrays_equals(), cmpoop is already > used for compare in same scenario. Hence I think cmpoop(a1, a2) > should also be applied here for short path? Where exactly, and in which repo? I can't see it, and I suspect that it's wrong. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sbergman at redhat.com Wed Jun 20 08:19:23 2018 From: sbergman at redhat.com (Stephan Bergmann) Date: Wed, 20 Jun 2018 10:19:23 +0200 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> Message-ID: <7955f64a-1725-55a1-db71-ccad30a5119c@redhat.com> On 20/06/18 08:27, Aleksey Shipilev wrote: > On 06/20/2018 08:16 AM, Stephan Bergmann wrote: >>> That's a safepoint SEGV.? It's deliberate.? If you step at that >>> point you'll enter the safepoint code. > > ... > >>> What exactly is the failure? >> >> The failure is that the process (running a C++ cppunittester executable, with an in-process >> instantiated JVM) terminates due to a SIGSEGV.? When inspecting the generated core file with gdb, it >> claims the above thread caused that "fatal" SIGSEGV. > > My first bet would be that cpuunittester had installed its own signal handlers that overwrote JVM's > SEGV handlers that are required for normal operation. You would need to use jsig to make JVM work in > that config, see: > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html cppunittester sets up all its signal handlers (which do /not/ include one for SIGSEGV) way before the in-process JVM is instantiated, so this always used to work fine without a need to LD_PRELOAD libjsig.so. However, trying with LD_PRELOAD nevertheless, I could no longer reproduce the (sporadic) failure. Odd. From Joshua.Zhu at arm.com Wed Jun 20 08:26:52 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Wed, 20 Jun 2018 08:26:52 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> Message-ID: http://hg.openjdk.java.net/jdk/jdk/file/e810abb27deb/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l5134 Best Regards, Joshua > -----Original Message----- > From: Andrew Haley > Sent: Wednesday, June 20, 2018 4:16 PM > > On 06/20/2018 08:26 AM, Joshua Zhu wrote: > > > I think you are saying read barrier in > > ShenandoahBarrierSetAssembler::obj_equals() implementation. > > Therefore I wonder why here we should directly compare these two oop > > instead of cmpoop. > > Yes. > > > And see current MacroAssembler::arrays_equals(), cmpoop is already > > used for compare in same scenario. Hence I think cmpoop(a1, a2) > > should also be applied here for short path? > > Where exactly, and in which repo? I can't see it, and I suspect that it's wrong. > > -- > 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 Wed Jun 20 08:31:01 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2018 09:31:01 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> Message-ID: <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> On 06/20/2018 12:45 AM, White, Derek wrote: > - Line 68: Could align to 64 bytes. We're going to load the first 64 bytes, may as well use one cache line. > > - Lines 71, 77, 79. You could comment these lines with "_coeff", "_log2", and "_L_tbl", for clearer correspondence to x86 code. > > - Line 204: I believe that we should be looking for equal to 0.0: > 204 // if (X = 0.0d) return -INFINITY; Yes. if (X == 0.0d). > - The (float)(zeroExponent(X) code was fun. > > - Are there any concerns about denormalized inputs? I didn't see any obvious problem in the code pulling aaprt and adding in exponents, but there's nothing obvious in that code to me. IEEE denormals don't usually require any special handling. > - The RETURN_MINF_OR_NAN block can generate a wide range of signaling and non-signaling NaNs. I forget how signaling Nans are treated in the Java math mode - are they just treated as quiet NaNs or are they never supposed to appear? Java doesn't care. However, it is possible to use DoubleToRawLongBits to extract some information, and this is fine. -- 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 Wed Jun 20 08:31:19 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 20 Jun 2018 09:31:19 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> Message-ID: <4d86e9b4-12ce-bec6-8221-504cdac68723@redhat.com> Hi Dmitrij, On 18/06/18 19:53, Dmitrij Pochepko wrote: > I added lots of documentation in a same manner as in Math::sin/cos patch. > > Please take a look at updated webrev: > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.05/ I am sorry I have not been able to work through the details of the actual generated code with enough attention to assess it's correctness (I have been very busy trying to check a fix for breakage to volatile handling caused by recent changes to the GC interface). I believe Andrew (Haley)'s and Derek's reviews are all you need in order to commit. I did work through the comments, name changes etc. The code is much improved and clearly indicates how the generated routine is supposed to operate, which means that if any error does turn up it should be possible to understand and fix it. Thank you for making a very helpful improvement. I'll do my best to find time to work through the sin and cos code once it is similarly commented. 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 Wed Jun 20 08:57:33 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2018 09:57:33 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> Message-ID: <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> On 06/20/2018 09:26 AM, Joshua Zhu wrote: > http://hg.openjdk.java.net/jdk/jdk/file/e810abb27deb/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l5134 Ah yes, you're right. It went in last week. I missed that. That is misleading code: it's relying on cmpoop providing the read barrier for both arrays, and it has a side effect on both pointers. We need to tidy this up a little bit for readability. Please lift the cmpoop(a1, a2); br(EQ, SAME); out of the if (UseSimpleArrayEquals) conditional and put a big red flag beside the cmpoop, like so: cmpoop(a1, a2); // Read barrier for a1 and a2. br(EQ, SAME); Then we don't need to use cmpoop anywhere else. The layout of the function header is wrong: void MacroAssembler::arrays_equals(Register a1, Register a2, Register tmp3, Register tmp4, Register tmp5, Register result, Register cnt1, int elem_size) { There should be no newline before the first brace. -- 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 Wed Jun 20 14:23:24 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Jun 2018 15:23:24 +0100 Subject: [aarch64-port-dev ] Against hidden read barriers in intrinsics Message-ID: We have some hand-coded AArch64 intrinsics, and they're being converted to the modular GC interface. However, I've noticed a dangerous coding practice that we should stop before it starts. In mainline jdk's MacroAssembler::arrays_equals, we have cmpoop(a1, a2); br(EQ, SAME); ... As of today, MacroAssembler::cmpoop() does a Brooks pointer dereference on *both* operands, and the following code relies on that for correctness. So, it's correct even for Shenandoah, but is a ticking bomb. If any programmer comes along and moves some code before that innocuous-looking cmpoop(), it'd be looking at stale copies of the data. When Shendandoah is merged into mainline we must not do this. Let us instead EXPLICITLY do resolve_for_read(IN_HEAP, a1); resolve_for_read(IN_HEAP, a2); ... cmp(a1, a2); This has the additional advantage that the read barrier is done as early as possible. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Jun 20 14:25:17 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 17:25:17 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <4d86e9b4-12ce-bec6-8221-504cdac68723@redhat.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <4d86e9b4-12ce-bec6-8221-504cdac68723@redhat.com> Message-ID: Hi, actually I updated and posted sin and cos at the same time as log, almost simultaneously. Thanks, Dmitrij On 20.06.2018 11:31, Andrew Dinn wrote: > Hi Dmitrij, > > On 18/06/18 19:53, Dmitrij Pochepko wrote: >> I added lots of documentation in a same manner as in Math::sin/cos patch. >> >> Please take a look at updated webrev: >> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.05/ > I am sorry I have not been able to work through the details of the > actual generated code with enough attention to assess it's correctness > (I have been very busy trying to check a fix for breakage to volatile > handling caused by recent changes to the GC interface). I believe Andrew > (Haley)'s and Derek's reviews are all you need in order to commit. > > I did work through the comments, name changes etc. The code is much > improved and clearly indicates how the generated routine is supposed to > operate, which means that if any error does turn up it should be > possible to understand and fix it. Thank you for making a very helpful > improvement. > > I'll do my best to find time to work through the sin and cos code once > it is similarly commented. > > 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 dmitrij.pochepko at bell-sw.com Wed Jun 20 14:26:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 17:26:12 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> Message-ID: <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> Hi, On 20.06.2018 11:31, Andrew Haley wrote: > On 06/20/2018 12:45 AM, White, Derek wrote: >> - Line 68: Could align to 64 bytes. We're going to load the first 64 bytes, may as well use one cache line. Agree. It'll be a bit better to use 64 bytes alignment. I changed it to 64 and tested the revised patch. I could not see a difference in synthetic benchmark, but single invocation might gain a small difference in case of L1 miss. >> >> - Lines 71, 77, 79. You could comment these lines with "_coeff", "_log2", and "_L_tbl", for clearer correspondence to x86 code. Added respective comment. >> >> - Line 204: I believe that we should be looking for equal to 0.0: >> 204 // if (X = 0.0d) return -INFINITY; > Yes. if (X == 0.0d). Thank you for noticing this typo. Assembly is correct. I fixed this comment. >> - The (float)(zeroExponent(X) code was fun. >> >> - Are there any concerns about denormalized inputs? I didn't see any obvious problem in the code pulling aaprt and adding in exponents, but there's nothing obvious in that code to me. > IEEE denormals don't usually require any special handling. There is no denormals-specific code in this algorithm. > >> - The RETURN_MINF_OR_NAN block can generate a wide range of signaling and non-signaling NaNs. I forget how signaling Nans are treated in the Java math mode - are they just treated as quiet NaNs or are they never supposed to appear? > Java doesn't care. However, it is possible to use DoubleToRawLongBits to > extract some information, and this is fine. I also aligned comments as in sin/cos patch and fixed the copyright. Here, the original code has table in HEX and also the article has HEX representation, so I kept HEX in the table. Please take a look at updated webrev: http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ Thanks, Dmitrij From roman at kennke.org Wed Jun 20 14:32:19 2018 From: roman at kennke.org (Roman Kennke) Date: Wed, 20 Jun 2018 16:32:19 +0200 Subject: [aarch64-port-dev ] Against hidden read barriers in intrinsics In-Reply-To: References: Message-ID: Am 20.06.2018 um 16:23 schrieb Andrew Haley: > We have some hand-coded AArch64 intrinsics, and they're being > converted to the modular GC interface. However, I've noticed a > dangerous coding practice that we should stop before it starts. > In mainline jdk's MacroAssembler::arrays_equals, we have > > cmpoop(a1, a2); > br(EQ, SAME); > ... > > As of today, MacroAssembler::cmpoop() does a Brooks pointer > dereference on *both* operands, and the following code relies on that > for correctness. So, it's correct even for Shenandoah, but is a > ticking bomb. If any programmer comes along and moves some code > before that innocuous-looking cmpoop(), it'd be looking at stale > copies of the data. > > When Shendandoah is merged into mainline we must not do this. Let us > instead EXPLICITLY do > > resolve_for_read(IN_HEAP, a1); > resolve_for_read(IN_HEAP, a2); > > ... > cmp(a1, a2); > > This has the additional advantage that the read barrier is done as > early as possible. > Hmm, but this would not be correct. There are two correct ways to do object comparison with Shenandoah: resolve_for_write(IN_HEAP, a1); resolve_for_write(IN_HEAP, a2); cmp(a1, a2); I.e. *ensure* that both objects a1 and a2 are stable in to-space, then compare. This is a fairly big hammer though: especially in the case of potentially large arrays, this might cause copying those arrays before comparing them. The saner alternative is: cmp(a1, a2); je(done); resolve_for_read(IN_HEAP, a1); resolve_for_read(IN_HEAP, a2); bind(done); I.e. it only employs read-barriers, and it only does so on the false-path. The logic behind this is a little tricky: we want to avoid false negatives. If we know that a1!=a2, it can only be because: - they are truly != - we're comparing from- and to-space copy of the same object we want to avoid the latter case. However, in this case we know that one copy is already in to-space. If they are the same object, doing read-barrier is sufficient to ensure we don't get false negatives. I believe Aarch64 we need additional load-load-membar: cmp(a1, a2); je(done); membar(); resolve_for_read(IN_HEAP, a1); resolve_for_read(IN_HEAP, a2); cmp(a1, a2); bind(done); to prevent re-ordering the RBs before the cmp. Do you think it's better to write out all this, possibly with #if INCLUDE_SHENANDOAHGC, in all the places where it needs to be? Or call some abstraction layer into cmpoop() to do the right thing? Maybe better document cmpoop() what it might or might not do, and what the user might or might not do with it? Roman From dmitrij.pochepko at bell-sw.com Wed Jun 20 14:45:12 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 17:45:12 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> Message-ID: <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Hi, can somebody take a look? Thanks, Dmitrij On 04.06.2018 18:50, Dmitrij Pochepko wrote: > Hi all, > > please review patch for JDK-8204289: AARCH64: enable math intrinsics > usage in interpreter and C1 > > This patch enables usage of math intrinsics for interpreter and C1 in > case intrinsics are implemented. Code follows that of x86 port. > > > Testing: I've merged this patch with implemented intrinsic and > launched jtreg tests and benchmark in 2 more modes: -Xint and > -XX:TieredStopAtLevel=3 > > Benchmark scores were improved as expected of intrinsic. All tests > passed. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > > > Thanks, > > Dmitrij > From dmitrij.pochepko at bell-sw.com Wed Jun 20 15:01:34 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 18:01:34 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205421 - AARCH64: StubCodeMark should be placed after alignment Message-ID: <38c69205-bce9-aa31-8d0f-6ddf3a1a8cf6@bell-sw.com> Hi, please review small patch for 8205421 - AARCH64: StubCodeMark should be placed after alignment This patch moves few StubCodeMark declarations after alignment code to have no alignment "nop" instructions in stub listing (like -XX:+PrintStubCode) CR: https://bugs.openjdk.java.net/browse/JDK-8205421 webrev: http://cr.openjdk.java.net/~dpochepk/8205421/webrev.01/ Testing: I checked patched build output via -XX:+PrintStubCode. Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 20 16:01:25 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 19:01:25 +0300 Subject: [aarch64-port-dev ] Against hidden read barriers in intrinsics In-Reply-To: References: Message-ID: <9798b3a1-536c-d137-c2a0-ce77499cee38@bell-sw.com> Hi, (I'm not a shenandoah expert and might get things wrong, so correct me in this case). We need to resolve brook pointers before accessing any data, potentially causing copy into to-space. If that's the case, then fix for "JDK-8203157: Object equals abstraction for BarrierSetAssembler" ( http://hg.openjdk.java.net/jdk/jdk/rev/8434981a4137 ) seems to be wrong. Specifically: hg.openjdk.java.net/jdk/jdk/annotate/8434981a4137/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l5141 This code (lines 5125-5134) is a bit tricky. It checks pointers for non-null value and load array length from array header to fire load instruction into ld pipelines as early as possible. And *after* that checks pointers for equality in parallel with loads, because such code pattern shows better result. In case of shenandoah it can cause load of potentially uninitialized data via brook pointers. Do I understand it correctly? Thanks, Dmitrij On 20.06.2018 17:32, Roman Kennke wrote: > Am 20.06.2018 um 16:23 schrieb Andrew Haley: >> We have some hand-coded AArch64 intrinsics, and they're being >> converted to the modular GC interface. However, I've noticed a >> dangerous coding practice that we should stop before it starts. >> In mainline jdk's MacroAssembler::arrays_equals, we have >> >> cmpoop(a1, a2); >> br(EQ, SAME); >> ... >> >> As of today, MacroAssembler::cmpoop() does a Brooks pointer >> dereference on *both* operands, and the following code relies on that >> for correctness. So, it's correct even for Shenandoah, but is a >> ticking bomb. If any programmer comes along and moves some code >> before that innocuous-looking cmpoop(), it'd be looking at stale >> copies of the data. >> >> When Shendandoah is merged into mainline we must not do this. Let us >> instead EXPLICITLY do >> >> resolve_for_read(IN_HEAP, a1); >> resolve_for_read(IN_HEAP, a2); >> >> ... >> cmp(a1, a2); >> >> This has the additional advantage that the read barrier is done as >> early as possible. >> > Hmm, but this would not be correct. There are two correct ways to do > object comparison with Shenandoah: > > resolve_for_write(IN_HEAP, a1); > resolve_for_write(IN_HEAP, a2); > cmp(a1, a2); > > I.e. *ensure* that both objects a1 and a2 are stable in to-space, then > compare. This is a fairly big hammer though: especially in the case of > potentially large arrays, this might cause copying those arrays before > comparing them. The saner alternative is: > > cmp(a1, a2); > je(done); > resolve_for_read(IN_HEAP, a1); > resolve_for_read(IN_HEAP, a2); > bind(done); > > I.e. it only employs read-barriers, and it only does so on the > false-path. The logic behind this is a little tricky: we want to avoid > false negatives. If we know that a1!=a2, it can only be because: > - they are truly != > - we're comparing from- and to-space copy of the same object > > we want to avoid the latter case. However, in this case we know that one > copy is already in to-space. If they are the same object, doing > read-barrier is sufficient to ensure we don't get false negatives. I > believe Aarch64 we need additional load-load-membar: > > > cmp(a1, a2); > je(done); > membar(); > resolve_for_read(IN_HEAP, a1); > resolve_for_read(IN_HEAP, a2); > cmp(a1, a2); > bind(done); > > to prevent re-ordering the RBs before the cmp. > > Do you think it's better to write out all this, possibly with #if > INCLUDE_SHENANDOAHGC, in all the places where it needs to be? Or call > some abstraction layer into cmpoop() to do the right thing? Maybe better > document cmpoop() what it might or might not do, and what the user might > or might not do with it? > > Roman From rkennke at redhat.com Wed Jun 20 16:10:21 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 Jun 2018 18:10:21 +0200 Subject: [aarch64-port-dev ] Against hidden read barriers in intrinsics In-Reply-To: <9798b3a1-536c-d137-c2a0-ce77499cee38@bell-sw.com> References: <9798b3a1-536c-d137-c2a0-ce77499cee38@bell-sw.com> Message-ID: <43b8a3b4-3cb9-5dcf-f02f-b97bd485774e@redhat.com> Am 20.06.2018 um 18:01 schrieb Dmitrij Pochepko: > Hi, > > (I'm not a shenandoah expert and might get things wrong, so correct me > in this case). > > We need to resolve brook pointers before accessing any data, potentially > causing copy into to-space. > > If that's the case, then fix for "JDK-8203157: Object equals abstraction > for BarrierSetAssembler" ( > http://hg.openjdk.java.net/jdk/jdk/rev/8434981a4137 ) seems to be wrong. > > Specifically: > hg.openjdk.java.net/jdk/jdk/annotate/8434981a4137/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l5141 > > > This code (lines 5125-5134) is a bit tricky. It checks pointers for > non-null value and load array length from array header to fire load > instruction into ld pipelines as early as possible. And *after* that > checks pointers for equality in parallel with loads, because such code > pattern shows better result. In case of shenandoah it can cause load of > potentially uninitialized data via brook pointers. > > Do I understand it correctly? I am not sure that I understand it correctly :-) Are you saying it might be wrong to load arraylengths from a1 and a2, because they have not been resolved via brooks ptr yet? This is a very special case because arraylength is immutable and it doesn't matter which copy we read it from. So yeah, I think the code is still correct with respect to the array length. Was that what you are trying to say/ask? Roman From Derek.White at cavium.com Wed Jun 20 16:51:04 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 20 Jun 2018 16:51:04 +0000 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> Message-ID: Hi Dmitrij, Looks good to me. Thanks! - Derek > -----Original Message----- > From: Dmitrij Pochepko [mailto:dmitrij.pochepko at bell-sw.com] > Sent: Wednesday, June 20, 2018 10:26 AM > To: Andrew Haley ; White, Derek > > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic > for Math.log > > External Email > > Hi, > > > On 20.06.2018 11:31, Andrew Haley wrote: > > On 06/20/2018 12:45 AM, White, Derek wrote: > >> - Line 68: Could align to 64 bytes. We're going to load the first 64 bytes, > may as well use one cache line. > Agree. It'll be a bit better to use 64 bytes alignment. I changed it to > 64 and tested the revised patch. I could not see a difference in synthetic > benchmark, but single invocation might gain a small difference in case of L1 > miss. > >> > >> - Lines 71, 77, 79. You could comment these lines with "_coeff", "_log2", > and "_L_tbl", for clearer correspondence to x86 code. > Added respective comment. > >> > >> - Line 204: I believe that we should be looking for equal to 0.0: > >> 204 // if (X = 0.0d) return -INFINITY; > > Yes. if (X == 0.0d). > Thank you for noticing this typo. Assembly is correct. I fixed this comment. > >> - The (float)(zeroExponent(X) code was fun. > >> > >> - Are there any concerns about denormalized inputs? I didn't see any > obvious problem in the code pulling aaprt and adding in exponents, but > there's nothing obvious in that code to me. > > IEEE denormals don't usually require any special handling. > There is no denormals-specific code in this algorithm. > > > >> - The RETURN_MINF_OR_NAN block can generate a wide range of > signaling and non-signaling NaNs. I forget how signaling Nans are treated in > the Java math mode - are they just treated as quiet NaNs or are they never > supposed to appear? > > Java doesn't care. However, it is possible to use DoubleToRawLongBits > > to extract some information, and this is fine. > > I also aligned comments as in sin/cos patch and fixed the copyright. > > Here, the original code has table in HEX and also the article has HEX > representation, so I kept HEX in the table. > > Please take a look at updated webrev: > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ > > Thanks, > Dmitrij From dmitrij.pochepko at bell-sw.com Wed Jun 20 18:41:27 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 20 Jun 2018 21:41:27 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> Message-ID: <450b4ba6-523a-cc26-abdd-c1b77882d928@bell-sw.com> Thank you for review! On 20.06.2018 19:51, White, Derek wrote: > Hi Dmitrij, > > Looks good to me. Thanks! > - Derek > >> -----Original Message----- >> From: Dmitrij Pochepko [mailto:dmitrij.pochepko at bell-sw.com] >> Sent: Wednesday, June 20, 2018 10:26 AM >> To: Andrew Haley ; White, Derek >> >> Cc: aarch64-port-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic >> for Math.log >> >> External Email >> >> Hi, >> >> >> On 20.06.2018 11:31, Andrew Haley wrote: >>> On 06/20/2018 12:45 AM, White, Derek wrote: >>>> - Line 68: Could align to 64 bytes. We're going to load the first 64 bytes, >> may as well use one cache line. >> Agree. It'll be a bit better to use 64 bytes alignment. I changed it to >> 64 and tested the revised patch. I could not see a difference in synthetic >> benchmark, but single invocation might gain a small difference in case of L1 >> miss. >>>> - Lines 71, 77, 79. You could comment these lines with "_coeff", "_log2", >> and "_L_tbl", for clearer correspondence to x86 code. >> Added respective comment. >>>> - Line 204: I believe that we should be looking for equal to 0.0: >>>> 204 // if (X = 0.0d) return -INFINITY; >>> Yes. if (X == 0.0d). >> Thank you for noticing this typo. Assembly is correct. I fixed this comment. >>>> - The (float)(zeroExponent(X) code was fun. >>>> >>>> - Are there any concerns about denormalized inputs? I didn't see any >> obvious problem in the code pulling aaprt and adding in exponents, but >> there's nothing obvious in that code to me. >>> IEEE denormals don't usually require any special handling. >> There is no denormals-specific code in this algorithm. >>>> - The RETURN_MINF_OR_NAN block can generate a wide range of >> signaling and non-signaling NaNs. I forget how signaling Nans are treated in >> the Java math mode - are they just treated as quiet NaNs or are they never >> supposed to appear? >>> Java doesn't care. However, it is possible to use DoubleToRawLongBits >>> to extract some information, and this is fine. >> I also aligned comments as in sin/cos patch and fixed the copyright. >> >> Here, the original code has table in HEX and also the article has HEX >> representation, so I kept HEX in the table. >> >> Please take a look at updated webrev: >> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ >> >> Thanks, >> Dmitrij From ci_notify at linaro.org Thu Jun 21 00:31:37 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 21 Jun 2018 00:31:37 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <357905466.2970.1529541098469.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/170/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/17 pass: 3,263; fail: 34; error: 4; not run: 11,619 Build 1: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 2: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 3: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 4: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 5: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 6: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 7: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 8: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 9: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 Build 11: aarch64/2018/jun/13 pass: 5,674; fail: 24; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/15 pass: 5,674; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/17 pass: 5,698; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/19 pass: 5,698; fail: 23; error: 2; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/17 pass: 8,329; fail: 595; error: 29 Build 1: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 2: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 3: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 4: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 5: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 6: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 7: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 8: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 9: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 10: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 Build 11: aarch64/2018/jun/13 pass: 8,435; fail: 576; error: 15 Build 12: aarch64/2018/jun/15 pass: 8,391; fail: 621; error: 16 Build 13: aarch64/2018/jun/17 pass: 8,423; fail: 594; error: 16 Build 14: aarch64/2018/jun/19 pass: 8,433; fail: 583; error: 17 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/17 pass: 3,864; fail: 6; error: 3 Build 1: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 2: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 3: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 4: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 5: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 6: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 7: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 8: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 9: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 10: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 Build 11: aarch64/2018/jun/13 pass: 3,891; fail: 6; error: 2 Build 12: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 13: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 Build 14: aarch64/2018/jun/19 pass: 3,894; fail: 4; error: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/17 pass: 3,274; fail: 31; error: 3; not run: 11,619 Build 1: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 2: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 3: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 4: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 5: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 6: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 7: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 8: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 10: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 Build 11: aarch64/2018/jun/13 pass: 5,682; fail: 23; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/15 pass: 5,681; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/17 pass: 5,705; fail: 22; error: 3; not run: 11,619 Build 14: aarch64/2018/jun/19 pass: 5,705; fail: 23; error: 2; not run: 11,619 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/17 pass: 8,349; fail: 587; error: 18 Build 1: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 2: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 3: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 4: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 5: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 6: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 7: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 8: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 9: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 10: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 Build 11: aarch64/2018/jun/13 pass: 8,423; fail: 589; error: 15 Build 12: aarch64/2018/jun/15 pass: 8,420; fail: 590; error: 19 Build 13: aarch64/2018/jun/17 pass: 8,436; fail: 581; error: 17 Build 14: aarch64/2018/jun/19 pass: 8,432; fail: 585; error: 17 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/17 pass: 3,861; fail: 6; error: 6 Build 1: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 2: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 3: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 4: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 5: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 6: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 7: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 8: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 9: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 10: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 Build 11: aarch64/2018/jun/13 pass: 3,892; fail: 6; error: 1 Build 12: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 13: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 Build 14: aarch64/2018/jun/19 pass: 3,894; fail: 4; error: 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): 0.62x Relative performance: Server critical-jOPS (nc): 0.50x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 66.58, Server: 111.14 Client 66.58 / Client 2014-04-01 (43.00): 1.55x Server 111.14 / Server 2014-04-01 (71.00): 1.57x 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 15 days. 2018-05-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/137/results/ 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ 2018-06-15 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/164/results/ 2018-06-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/166/results/ 2018-06-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/168/results/ 2018-06-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/170/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Thu Jun 21 08:18:51 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 09:18:51 +0100 Subject: [aarch64-port-dev ] Against hidden read barriers in intrinsics In-Reply-To: References: Message-ID: <1c9a56cf-0ff8-d7d7-d425-66cc7846e91c@redhat.com> On 06/20/2018 03:32 PM, Roman Kennke wrote: > Am 20.06.2018 um 16:23 schrieb Andrew Haley: >> We have some hand-coded AArch64 intrinsics, and they're being >> converted to the modular GC interface. However, I've noticed a >> dangerous coding practice that we should stop before it starts. >> In mainline jdk's MacroAssembler::arrays_equals, we have >> >> cmpoop(a1, a2); >> br(EQ, SAME); >> ... >> >> As of today, MacroAssembler::cmpoop() does a Brooks pointer >> dereference on *both* operands, and the following code relies on that >> for correctness. So, it's correct even for Shenandoah, but is a >> ticking bomb. If any programmer comes along and moves some code >> before that innocuous-looking cmpoop(), it'd be looking at stale >> copies of the data. >> >> When Shendandoah is merged into mainline we must not do this. Let us >> instead EXPLICITLY do >> >> resolve_for_read(IN_HEAP, a1); >> resolve_for_read(IN_HEAP, a2); >> >> ... >> cmp(a1, a2); >> >> This has the additional advantage that the read barrier is done as >> early as possible. >> > > Hmm, but this would not be correct. There are two correct ways to do > object comparison with Shenandoah: > > resolve_for_write(IN_HEAP, a1); > resolve_for_write(IN_HEAP, a2); > cmp(a1, a2); Fine by me: I just want it to be explicit. > I.e. *ensure* that both objects a1 and a2 are stable in to-space, then > compare. This is a fairly big hammer though: especially in the case of > potentially large arrays, this might cause copying those arrays before > comparing them. The saner alternative is: > > cmp(a1, a2); > je(done); > resolve_for_read(IN_HEAP, a1); > resolve_for_read(IN_HEAP, a2); > bind(done); > > I.e. it only employs read-barriers, and it only does so on the > false-path. The logic behind this is a little tricky: we want to avoid > false negatives. If we know that a1!=a2, it can only be because: > - they are truly != > - we're comparing from- and to-space copy of the same object > > we want to avoid the latter case. However, in this case we know that one > copy is already in to-space. If they are the same object, doing > read-barrier is sufficient to ensure we don't get false negatives. I > believe Aarch64 we need additional load-load-membar: > > > cmp(a1, a2); > je(done); > membar(); > resolve_for_read(IN_HEAP, a1); > resolve_for_read(IN_HEAP, a2); > cmp(a1, a2); > bind(done); > > to prevent re-ordering the RBs before the cmp. Got it. > Do you think it's better to write out all this, possibly with #if > INCLUDE_SHENANDOAHGC, in all the places where it needs to be? Or call > some abstraction layer into cmpoop() to do the right thing? Maybe better > document cmpoop() what it might or might not do, and what the user might > or might not do with it? cmpoop() with a side effect on its input operands is extremely misleading, and therefore dangerous. I'd rewrite its implementation to move the operands into rscratch1 and rscratch2 and compare those, so that no-one is even slightly tempted to use it for side effects. Of course we don't have to do that where we're short of registers, but cmpoop()'s specification should perhaps say that it may or may not have a side effect on a1 and a2. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Thu Jun 21 09:22:31 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Jun 2018 11:22:31 +0200 Subject: [aarch64-port-dev ] RFR: [backport] overflow integer during size calculation Message-ID: <5e44b4cc-1540-8af9-abde-6e7352b8a867@redhat.com> This fixes an important regression found by QA when running with Shenandoah. # HG changeset patch # User zgu # Date 1529419060 14400 # Tue Jun 19 10:37:40 2018 -0400 # Node ID 923b7475c897b75d9d3ad5350bb3f3edcb32a413 # Parent 67e063d99bbd5ce67f4197f4e15561e9a634e7e2 [backport] overflow integer during size calculation diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp b/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp --- a/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp @@ -94,10 +94,12 @@ inline void ShenandoahConcurrentMark::count_liveness_humongous(oop obj) { shenandoah_assert_in_correct_region(NULL, obj); size_t region_idx = _heap->heap_region_index_containing(obj); - int size = obj->size() + BrooksPointer::word_size(); + size_t size = obj->size() + BrooksPointer::word_size(); size_t num_regions = ShenandoahHeapRegion::required_regions(size * HeapWordSize); + for (size_t i = region_idx; i < region_idx + num_regions; i++) { ShenandoahHeapRegion* chain_reg = _heap->get_region(i); + assert(chain_reg->is_humongous(), "Expecting a humongous region"); chain_reg->increase_live_data_gc_words(chain_reg->used() >> LogHeapWordSize); } } From shade at redhat.com Thu Jun 21 09:43:33 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Jun 2018 11:43:33 +0200 Subject: [aarch64-port-dev ] RFR: [backport] overflow integer during size calculation In-Reply-To: <5e44b4cc-1540-8af9-abde-6e7352b8a867@redhat.com> References: <5e44b4cc-1540-8af9-abde-6e7352b8a867@redhat.com> Message-ID: On 06/21/2018 11:22 AM, Roman Kennke wrote: > This fixes an important regression found by QA when running with Shenandoah. > > > # HG changeset patch > # User zgu > # Date 1529419060 14400 > # Tue Jun 19 10:37:40 2018 -0400 > # Node ID 923b7475c897b75d9d3ad5350bb3f3edcb32a413 > # Parent 67e063d99bbd5ce67f4197f4e15561e9a634e7e2 > [backport] overflow integer during size calculation > > diff --git > a/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp > b/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp > --- > a/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp > +++ > b/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp > @@ -94,10 +94,12 @@ > inline void ShenandoahConcurrentMark::count_liveness_humongous(oop obj) { > shenandoah_assert_in_correct_region(NULL, obj); > size_t region_idx = _heap->heap_region_index_containing(obj); > - int size = obj->size() + BrooksPointer::word_size(); > + size_t size = obj->size() + BrooksPointer::word_size(); > size_t num_regions = ShenandoahHeapRegion::required_regions(size * > HeapWordSize); > + > for (size_t i = region_idx; i < region_idx + num_regions; i++) { > ShenandoahHeapRegion* chain_reg = _heap->get_region(i); > + assert(chain_reg->is_humongous(), "Expecting a humongous region"); > chain_reg->increase_live_data_gc_words(chain_reg->used() >> > LogHeapWordSize); > } > } Looks good. -Aleksey From aph at redhat.com Thu Jun 21 09:51:09 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 10:51:09 +0100 Subject: [aarch64-port-dev ] RFR: [backport] overflow integer during size calculation In-Reply-To: <5e44b4cc-1540-8af9-abde-6e7352b8a867@redhat.com> References: <5e44b4cc-1540-8af9-abde-6e7352b8a867@redhat.com> Message-ID: On 06/21/2018 10:22 AM, Roman Kennke wrote: > - int size = obj->size() + BrooksPointer::word_size(); > + size_t size = obj->size() + BrooksPointer::word_size(); Ouch! Yes. That's a heck of a humongous object. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From roman at kennke.org Thu Jun 21 09:51:49 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:49 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 324208da2fdf Message-ID: <201806210951.w5L9pngU016289@aojmv0008.oracle.com> Changeset: ab1b676be793 Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/ab1b676be793 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 324208da2fdf ! .hgtags From roman at kennke.org Thu Jun 21 09:51:51 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset f3da49ee5753 Message-ID: <201806210951.w5L9ppuf016414@aojmv0008.oracle.com> Changeset: 86eb5cd065cd Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/86eb5cd065cd Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset f3da49ee5753 ! .hgtags From roman at kennke.org Thu Jun 21 09:51:50 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:50 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset b391cf7f2548 Message-ID: <201806210951.w5L9po8F016351@aojmv0008.oracle.com> Changeset: 23092a1d1f41 Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/23092a1d1f41 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset b391cf7f2548 ! .hgtags From roman at kennke.org Thu Jun 21 09:51:53 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:53 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 6a4e0561f7f1 Message-ID: <201806210951.w5L9prqD016529@aojmv0008.oracle.com> Changeset: c7f80dce50c2 Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/c7f80dce50c2 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 6a4e0561f7f1 ! .hgtags From roman at kennke.org Thu Jun 21 09:51:55 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:55 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 91a125cedb53 Message-ID: <201806210951.w5L9ptY9016622@aojmv0008.oracle.com> Changeset: 1bced2585515 Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/1bced2585515 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 91a125cedb53 ! .hgtags From roman at kennke.org Thu Jun 21 09:51:56 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:56 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset e5fd3e9c4bef Message-ID: <201806210951.w5L9puYn016682@aojmv0008.oracle.com> Changeset: c952e1a82bd0 Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c952e1a82bd0 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset e5fd3e9c4bef ! .hgtags From roman at kennke.org Thu Jun 21 09:51:57 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:57 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset fb17b2f48ea9 Message-ID: <201806210951.w5L9pvbV016691@aojmv0008.oracle.com> Changeset: 794e779663ea Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/794e779663ea Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset fb17b2f48ea9 ! .hgtags From roman at kennke.org Thu Jun 21 09:51:59 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 21 Jun 2018 09:51:59 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 2 new changesets Message-ID: <201806210951.w5L9pxGQ016723@aojmv0008.oracle.com> Changeset: 923b7475c897 Author: zgu Date: 2018-06-19 10:37 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/923b7475c897 [backport] overflow integer during size calculation ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp Changeset: 8092b3ede115 Author: rkennke Date: 2018-06-21 11:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8092b3ede115 Added tag aarch64-shenandoah-jdk8u172-b11--shenandoah-merge-2018-06-21 for changeset 923b7475c897 ! .hgtags From sbergman at redhat.com Thu Jun 21 13:04:33 2018 From: sbergman at redhat.com (Stephan Bergmann) Date: Thu, 21 Jun 2018 15:04:33 +0200 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: <7955f64a-1725-55a1-db71-ccad30a5119c@redhat.com> References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> <7955f64a-1725-55a1-db71-ccad30a5119c@redhat.com> Message-ID: <5c0b52d9-d2ce-72d0-5740-33a41dec281d@redhat.com> On 20/06/18 10:19, Stephan Bergmann wrote: > cppunittester sets up all its signal handlers (which do /not/ include > one for SIGSEGV) way before the in-process JVM is instantiated, so this > always used to work fine without a need to LD_PRELOAD libjsig.so. > However, trying with LD_PRELOAD nevertheless, I could no longer > reproduce the (sporadic) failure.? Odd. Ha, turns out that while the cppunittester process didn't set a SIGSEGV handler at start, it erroneously reset whatever SIGSEGV handler to SIG_DFL towards the end of execution, shortly before exit. And with some luck, JVM threads executing JIT'ed code could apparently still run at that time, inducing SIGSEGV that would rely on the JVM's handler. Appears to be just a coincidence that I only experienced that crash with OpenJDK 10 on aarch64. Sorry for the noise... From Joshua.Zhu at arm.com Thu Jun 21 13:09:27 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Thu, 21 Jun 2018 13:09:27 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> Message-ID: Hi Andrew, Thanks for your comments. I have updated new webrev at http://cr.openjdk.java.net/~zyao/8205004/webrev.03/ Best Regards, Joshua > -----Original Message----- > From: Andrew Haley > Sent: Wednesday, June 20, 2018 4:58 PM > > On 06/20/2018 09:26 AM, Joshua Zhu wrote: > > http://hg.openjdk.java.net/jdk/jdk/file/e810abb27deb/src/hotspot/cpu/a > > arch64/macroAssembler_aarch64.cpp#l5134 > > Ah yes, you're right. It went in last week. I missed that. That is misleading > code: it's relying on cmpoop providing the read barrier for both arrays, and it > has a side effect on both pointers. > > We need to tidy this up a little bit for readability. Please lift the > > cmpoop(a1, a2); > br(EQ, SAME); > > out of the if (UseSimpleArrayEquals) conditional and put a big red flag beside > the cmpoop, like so: > > cmpoop(a1, a2); // Read barrier for a1 and a2. > br(EQ, SAME); > > Then we don't need to use cmpoop anywhere else. > > The layout of the function header is wrong: > > void MacroAssembler::arrays_equals(Register a1, Register a2, Register tmp3, > Register tmp4, Register tmp5, Register result, > Register cnt1, int elem_size) { > > There should be no newline before the first brace. > > -- > 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 Thu Jun 21 13:16:36 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 14:16:36 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> Message-ID: On 06/21/2018 02:09 PM, Joshua Zhu wrote: > I have updated new webrev at > http://cr.openjdk.java.net/~zyao/8205004/webrev.03/ That looks right. Dmitrij, do you agree it's correct now? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Jun 21 13:24:35 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 16:24:35 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> Message-ID: <431f6924-b386-c311-9a97-a2c7f146e6c3@bell-sw.com> On 21.06.2018 16:16, Andrew Haley wrote: > On 06/21/2018 02:09 PM, Joshua Zhu wrote: >> I have updated new webrev at >> http://cr.openjdk.java.net/~zyao/8205004/webrev.03/ > That looks right. Dmitrij, do you agree it's correct now? > Yes. Looks good. From dmitrij.pochepko at bell-sw.com Thu Jun 21 13:42:16 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 16:42:16 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205474 - AARCH64: wrong zr encoding for ccmp instruction Message-ID: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> Hi, please review small patch for 8205474 - AARCH64: wrong zr encoding for ccmp instruction ccmp instruction hits assert while trying to compare with zero register. Root reason is that zero register needs special handling: zr has internal number 32 in hotspot, while AARCH64 spec require number 31. This patch fix it. webrev: http://cr.openjdk.java.net/~dpochepk/8205474/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8205474 Testing: I created intrinsic which use ccmp with zr and sanity passed. Thanks, Dmitrij From dmitrij.pochepko at bell-sw.com Thu Jun 21 13:51:06 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 16:51:06 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> <748399ee-0104-2fc6-dac0-47359525a8c8@samersoff.net> <1ab32ad5-4e1e-6051-e419-b52fefaef357@redhat.com> Message-ID: <7ded1b58-e2a6-ffb9-7f31-6180b36411f0@bell-sw.com> Looks good(not a reviewer) On 18.06.2018 17:20, Dmitry Samersoff wrote: > Comments changed in-place. > > On 18.06.2018 15:49, Andrew Haley wrote: >> On 06/18/2018 01:46 PM, Dmitry Samersoff wrote: >>> I'll copy your explanation of what is happening to comments. >>> >>> Are you ok with the fix it self? >> Sure. For AArch64 only. >> > From aph at redhat.com Thu Jun 21 13:56:00 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 14:56:00 +0100 Subject: [aarch64-port-dev ] RFR(S): 8205474 - AARCH64: wrong zr encoding for ccmp instruction In-Reply-To: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> References: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> Message-ID: On 06/21/2018 02:42 PM, Dmitrij Pochepko wrote: > please review small patch for 8205474 - AARCH64: wrong zr encoding for > ccmp instruction > > ccmp instruction hits assert while trying to compare with zero register. > Root reason is that zero register needs special handling: zr has > internal number 32 in hotspot, while AARCH64 spec require number 31. Oh Lord, I wrote that horrible code. I'm sorry. It was a long time ago. :-) > This patch fix it. > > webrev: http://cr.openjdk.java.net/~dpochepk/8205474/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8205474 OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Jun 21 13:57:39 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 16:57:39 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205474 - AARCH64: wrong zr encoding for ccmp instruction In-Reply-To: References: <4a67bf49-dd03-d90f-f1ab-fd5c0423c62e@bell-sw.com> Message-ID: Thank you for review! On 21.06.2018 16:56, Andrew Haley wrote: > On 06/21/2018 02:42 PM, Dmitrij Pochepko wrote: >> please review small patch for 8205474 - AARCH64: wrong zr encoding for >> ccmp instruction >> >> ccmp instruction hits assert while trying to compare with zero register. >> Root reason is that zero register needs special handling: zr has >> internal number 32 in hotspot, while AARCH64 spec require number 31. > Oh Lord, I wrote that horrible code. I'm sorry. It was a long time ago. > :-) > >> This patch fix it. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8205474/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8205474 > OK, thanks. > From dms at samersoff.net Thu Jun 21 14:05:47 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Thu, 21 Jun 2018 17:05:47 +0300 Subject: [aarch64-port-dev ] RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender In-Reply-To: <7ded1b58-e2a6-ffb9-7f31-6180b36411f0@bell-sw.com> References: <930b4686-dcf6-5f01-f492-4e65a25145c3@samersoff.net> <3d59b75a-2615-3181-4446-bcc5e64d6b1d@samersoff.net> <748399ee-0104-2fc6-dac0-47359525a8c8@samersoff.net> <1ab32ad5-4e1e-6051-e419-b52fefaef357@redhat.com> <7ded1b58-e2a6-ffb9-7f31-6180b36411f0@bell-sw.com> Message-ID: Thank you! On 21.06.2018 16:51, Dmitrij Pochepko wrote: > Looks good(not a reviewer) > > > On 18.06.2018 17:20, Dmitry Samersoff wrote: >> Comments changed in-place. >> >> On 18.06.2018 15:49, Andrew Haley wrote: >>> On 06/18/2018 01:46 PM, Dmitry Samersoff wrote: >>>> I'll copy your explanation of what is happening to comments. >>>> >>>> Are you ok with the fix it self? >>> Sure.? For AArch64 only. >>> >> > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From shade at redhat.com Thu Jun 21 14:14:26 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Jun 2018 16:14:26 +0200 Subject: [aarch64-port-dev ] Sporadic crashes on aarch64 after switching from OpenJDK 9 to 10 In-Reply-To: <5c0b52d9-d2ce-72d0-5740-33a41dec281d@redhat.com> References: <4e76135d-2444-9f67-96f6-92ab1ece222e@redhat.com> <72b55b26-c5e7-4b5f-8e31-5934ddf84eab@redhat.com> <7955f64a-1725-55a1-db71-ccad30a5119c@redhat.com> <5c0b52d9-d2ce-72d0-5740-33a41dec281d@redhat.com> Message-ID: On 06/21/2018 03:04 PM, Stephan Bergmann wrote: > On 20/06/18 10:19, Stephan Bergmann wrote: >> cppunittester sets up all its signal handlers (which do /not/ include one for SIGSEGV) way before >> the in-process JVM is instantiated, so this always used to work fine without a need to LD_PRELOAD >> libjsig.so. However, trying with LD_PRELOAD nevertheless, I could no longer reproduce the >> (sporadic) failure.? Odd. > > Ha, turns out that while the cppunittester process didn't set a SIGSEGV handler at start, it > erroneously reset whatever SIGSEGV handler to SIG_DFL towards the end of execution, shortly before > exit.? And with some luck, JVM threads executing JIT'ed code could apparently still run at that > time, inducing SIGSEGV that would rely on the JVM's handler. > > Appears to be just a coincidence that I only experienced that crash with OpenJDK 10 on aarch64.? > Sorry for the noise... Yup, no problem! Years ago I wasted a day trying to diagnose a crash like that, before learning that users' config had a weird native library that defined its own SEGV handler. Since then my knee-jerk reaction to any crash that originates from the safepoint poll is cocking a shotgun and looking for a bastard native code that touched any signal handlers. -Aleksey From adinn at redhat.com Thu Jun 21 14:20:21 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Jun 2018 15:20:21 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error Message-ID: The following patch fixes a problem in the AArch64 port which was caused by the introduction of the GC API which delegates responsibility for barrier generation to GC code (JDK-8202377) webrev: http://cr.openjdk.java.net/~adinn/8204331/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8204331 The new G1 barrier assembler in combination with the C2 fence generator introduced a few small changes to the the memory flow layout in ideal subgraphs arising from (normal and Unsafe) volatile stores and (Unsafe) volatile CASes. This affects the results returned by the AARch64 predicates employed by ad file instructions to suppress generation of certain hw memory barriers instructions and, instead, generate acquiring loads + releasing stores. The change was caught by asserts in the CAS code which detected the new, unexpected graph shape. Reviews would be very welcome! The Patch: The fix involves several small changes to reflect each change introduced by the GC code. 1) Re-ordering of trailing volatile/cpu order barriers The C2 fence generator class reversed the order of the volatile and cpu order pair generated at the end of an Unsafe volatile store subgraph (from Volatile=>CPUOrder to CPUOrder=>Volatile). This is now uniform with the order of the trailing acquire/cpu order barriers (CPUOrder=>Acquire). The relevant predicates have been updated to expect and check for barriers in this order. 2) Extra memory flows in CAS graphs. Unsafe CASObject graphs for GCs which employ a conditional card mark (G1GC or CMS+USeCondCardMark) may now include an extra If=>IfTrue/IfFalse ===> Region+Phi(BotIdx) between the card mark memory barrier and the trailing cpu order/acquire barriers. The new IfNode models a test of the boolean result returned by the CAS operation. It gets wrapped up in the barrier flow because of the different order of generation of the GC post barrier and the (SCMemProj) memory projection from the CAS itself. Previously the CAS and SCMemProj simply fed direct into the trailing barriers so there was no need to check the GC post-barrier subgraph. Now a CASObject looks more like a volatile StoreN/P, both of them feeding their memory flow into the card mark membar. In consequence, testing for a CASObject now requires two stages as per a StoreN/P -- matching the pair of memory subgraphs from leading to card mark membar and from card mark to trailing membar. The predicates which traverse the memory flow between leading and trailing/card mark membars have been updated so they now look for the same pattern in either case, modulo the presence of a Store or a CAS+SCMemProj pair. In the case where a card mark member is present this new test is now combined with a check on the trailing graph in the CAS case, just as with a StoreN/P. The predicates which traverse the memory flow between card mark and trailing membars have been updated to search through (potentially) one more Phi(BotIdx) link. So, the maximum number of Phis to indirect trough has been increased to 4 for G1GC and 1 for ConcMarkSweep+UseCondCardMark. Testing: This has been tested by running tier1 tests. All the tests which were previously failing are now working. There were 5 failures due to timeouts which do not appear to relate to this issue. The code has also been tested by printing generated code for some simple usages of volatile load/store and CAS, checking the generated code by eyeball. This was repeated for SerialGC, ParallelGC, ConcMarkSweep-UseCondCardMark, ConcMarkSweep+UseCondCardMark and G1GC. It would be good to also run further tests (esp jcstress). However, since this breakage is stopping testing of other changes and since it seems to remedy the problem in common cases at least I suggest committing this fix now and running these tests afterwards. Additional test specific to this issue?: There are currently no proper tests for this code as it was difficult to know how to identify what code gets generated. Detection of failures is left to asserts in the predicates. That approach has worked in the present case but only after a breaking change has been pushed and only by detecting one of several breaking changes. So the current regime is rather fragile. It would be good to have some jtreg tests to help detect breakages like this more quickly and effectively. A slowdebug build with an available hsdis-aarch64.so could be used to print out generated assembly. Usefully, in debug mode the C2 back end will print out block comments indicating both where membars have been placed and where they have been elided. If a jtreg test was run in an otherjvm with CompileCommand options to compile and print target methods then the output could be scanned to look for the relevant membar/membar elided comments and for presence or absence of ldar/stlr and ldaxr/stlxr instructions. This would be enough to test that basic transformations are sound. Is it possible to rely on an hsdis library being available in jtreg tests? Alternatively, is it possible to make execution of the test conditional on the library being present? 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 dmitrij.pochepko at bell-sw.com Thu Jun 21 15:30:13 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 18:30:13 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> Message-ID: Hi, I need official reviewer to review this version together with "8204289: AARCH64: enable math intrinsics usage in interpreter and C1" to wrap this up. Thanks, Dmitrij On 20.06.2018 19:51, White, Derek wrote: > Hi Dmitrij, > > Looks good to me. Thanks! > - Derek > >> -----Original Message----- >> From: Dmitrij Pochepko [mailto:dmitrij.pochepko at bell-sw.com] >> Sent: Wednesday, June 20, 2018 10:26 AM >> To: Andrew Haley ; White, Derek >> >> Cc: aarch64-port-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic >> for Math.log >> >> External Email >> >> Hi, >> >> >> On 20.06.2018 11:31, Andrew Haley wrote: >>> On 06/20/2018 12:45 AM, White, Derek wrote: >>>> - Line 68: Could align to 64 bytes. We're going to load the first 64 bytes, >> may as well use one cache line. >> Agree. It'll be a bit better to use 64 bytes alignment. I changed it to >> 64 and tested the revised patch. I could not see a difference in synthetic >> benchmark, but single invocation might gain a small difference in case of L1 >> miss. >>>> - Lines 71, 77, 79. You could comment these lines with "_coeff", "_log2", >> and "_L_tbl", for clearer correspondence to x86 code. >> Added respective comment. >>>> - Line 204: I believe that we should be looking for equal to 0.0: >>>> 204 // if (X = 0.0d) return -INFINITY; >>> Yes. if (X == 0.0d). >> Thank you for noticing this typo. Assembly is correct. I fixed this comment. >>>> - The (float)(zeroExponent(X) code was fun. >>>> >>>> - Are there any concerns about denormalized inputs? I didn't see any >> obvious problem in the code pulling aaprt and adding in exponents, but >> there's nothing obvious in that code to me. >>> IEEE denormals don't usually require any special handling. >> There is no denormals-specific code in this algorithm. >>>> - The RETURN_MINF_OR_NAN block can generate a wide range of >> signaling and non-signaling NaNs. I forget how signaling Nans are treated in >> the Java math mode - are they just treated as quiet NaNs or are they never >> supposed to appear? >>> Java doesn't care. However, it is possible to use DoubleToRawLongBits >>> to extract some information, and this is fine. >> I also aligned comments as in sin/cos patch and fixed the copyright. >> >> Here, the original code has table in HEX and also the article has HEX >> representation, so I kept HEX in the table. >> >> Please take a look at updated webrev: >> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ >> >> Thanks, >> Dmitrij From aph at redhat.com Thu Jun 21 16:30:06 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 Jun 2018 17:30:06 +0100 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: On 06/20/2018 03:45 PM, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8204289 Looks OK, but... What is the conditional code in 270 case Interpreter::java_lang_math_log : 271 if (StubRoutines::dlog() == NULL) { 272 fn = CAST_FROM_FN_PTR(address, SharedRuntime::dlog); 273 } else { 274 fn = CAST_FROM_FN_PTR(address, StubRoutines::dlog()); 275 } for? When would StubRoutines::dlog() be NULL? We don't pay any attention to vmIntrinsics::is_intrinsic_available(), so AFAICS it's always there. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Thu Jun 21 17:49:26 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Jun 2018 19:49:26 +0200 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: <75b946c0-44ee-109e-471d-32ba2cdf142e@redhat.com> Hi Andrew, thanks so much for fixing this! Also, very nice ASCII drawings and explanations! :-) As far as I can tell, the patch is good. I'm wondering why it's worth to go through that effort to verify the correct shape of CAS and similar nodes, and keep maintaining this code in light of changes (Shenandoah will be the next headache to fix this). Do the instruction only match those particular shapes, and if it changes, it'd throw off the matcher badly? Thanks, Roman > The following patch fixes a problem in the AArch64 port which was caused > by the introduction of the GC API which delegates responsibility for > barrier generation to GC code (JDK-8202377) > > webrev: http://cr.openjdk.java.net/~adinn/8204331/webrev.00/ > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8204331 > > The new G1 barrier assembler in combination with the C2 fence generator > introduced a few small changes to the the memory flow layout in ideal > subgraphs arising from (normal and Unsafe) volatile stores and (Unsafe) > volatile CASes. This affects the results returned by the AARch64 > predicates employed by ad file instructions to suppress generation of > certain hw memory barriers instructions and, instead, generate acquiring > loads + releasing stores. The change was caught by asserts in the CAS > code which detected the new, unexpected graph shape. > > Reviews would be very welcome! > > The Patch: > > The fix involves several small changes to reflect each change introduced > by the GC code. > > 1) Re-ordering of trailing volatile/cpu order barriers > The C2 fence generator class reversed the order of the volatile and cpu > order pair generated at the end of an Unsafe volatile store subgraph > (from Volatile=>CPUOrder to CPUOrder=>Volatile). This is now uniform > with the order of the trailing acquire/cpu order barriers > (CPUOrder=>Acquire). > > The relevant predicates have been updated to expect and check for > barriers in this order. > > 2) Extra memory flows in CAS graphs. Unsafe CASObject graphs for GCs > which employ a conditional card mark (G1GC or CMS+USeCondCardMark) may > now include an extra If=>IfTrue/IfFalse ===> Region+Phi(BotIdx) between > the card mark memory barrier and the trailing cpu order/acquire > barriers. The new IfNode models a test of the boolean result returned by > the CAS operation. It gets wrapped up in the barrier flow because of the > different order of generation of the GC post barrier and the (SCMemProj) > memory projection from the CAS itself. > > Previously the CAS and SCMemProj simply fed direct into the trailing > barriers so there was no need to check the GC post-barrier subgraph. Now > a CASObject looks more like a volatile StoreN/P, both of them feeding > their memory flow into the card mark membar. In consequence, testing for > a CASObject now requires two stages as per a StoreN/P -- matching the > pair of memory subgraphs from leading to card mark membar and from card > mark to trailing membar. > > The predicates which traverse the memory flow between leading and > trailing/card mark membars have been updated so they now look for the > same pattern in either case, modulo the presence of a Store or a > CAS+SCMemProj pair. In the case where a card mark member is present this > new test is now combined with a check on the trailing graph in the CAS > case, just as with a StoreN/P. > > The predicates which traverse the memory flow between card mark and > trailing membars have been updated to search through (potentially) one > more Phi(BotIdx) link. So, the maximum number of Phis to indirect trough > has been increased to 4 for G1GC and 1 for ConcMarkSweep+UseCondCardMark. > > Testing: > > This has been tested by running tier1 tests. All the tests which were > previously failing are now working. There were 5 failures due to > timeouts which do not appear to relate to this issue. > > The code has also been tested by printing generated code for some simple > usages of volatile load/store and CAS, checking the generated code by > eyeball. This was repeated for SerialGC, ParallelGC, > ConcMarkSweep-UseCondCardMark, ConcMarkSweep+UseCondCardMark and G1GC. > > It would be good to also run further tests (esp jcstress). However, > since this breakage is stopping testing of other changes and since it > seems to remedy the problem in common cases at least I suggest > committing this fix now and running these tests afterwards. > > Additional test specific to this issue?: > > There are currently no proper tests for this code as it was difficult to > know how to identify what code gets generated. Detection of failures is > left to asserts in the predicates. That approach has worked in the > present case but only after a breaking change has been pushed and only > by detecting one of several breaking changes. So the current regime is > rather fragile. It would be good to have some jtreg tests to help detect > breakages like this more quickly and effectively. > > A slowdebug build with an available hsdis-aarch64.so could be used to > print out generated assembly. Usefully, in debug mode the C2 back end > will print out block comments indicating both where membars have been > placed and where they have been elided. If a jtreg test was run in an > otherjvm with CompileCommand options to compile and print target methods > then the output could be scanned to look for the relevant membar/membar > elided comments and for presence or absence of ldar/stlr and ldaxr/stlxr > instructions. This would be enough to test that basic transformations > are sound. > > Is it possible to rely on an hsdis library being available in jtreg > tests? Alternatively, is it possible to make execution of the test > conditional on the library being present? > > 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 dmitrij.pochepko at bell-sw.com Thu Jun 21 18:06:55 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 21 Jun 2018 21:06:55 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: <5e2e79cd-8401-f239-d028-0f1ad9a80ff4@bell-sw.com> Thanks for noticing it. I now think it make sense to add vmIntrinsics::is_intrinsic_available check for math intrinsics in this patch. It will make it aligned with other architecture like this: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.02/ What do you think about it? Thanks, Dmitrij On 21.06.2018 19:30, Andrew Haley wrote: > On 06/20/2018 03:45 PM, Dmitrij Pochepko wrote: >> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > Looks OK, but... What is the conditional code in > > 270 case Interpreter::java_lang_math_log : > 271 if (StubRoutines::dlog() == NULL) { > 272 fn = CAST_FROM_FN_PTR(address, SharedRuntime::dlog); > 273 } else { > 274 fn = CAST_FROM_FN_PTR(address, StubRoutines::dlog()); > 275 } > > for? When would StubRoutines::dlog() be NULL? We don't pay any attention > to vmIntrinsics::is_intrinsic_available(), so AFAICS it's always there. > From Derek.White at cavium.com Fri Jun 22 01:40:22 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 22 Jun 2018 01:40:22 +0000 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Hi Dmitrij, There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines 815, 828, 829, 849, 850. I didn't follow all of the differences between the change from call_runtime to __ call_runtime_leaf, (although I see that it follows the x86 code.) So I wouldn't call this a full review. Thanks, - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > Sent: Wednesday, June 20, 2018 10:45 AM > To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math > intrinsics usage in interpreter and C1 > > External Email > > Hi, > > > can somebody take a look? > > > Thanks, > > Dmitrij > > > On 04.06.2018 18:50, Dmitrij Pochepko wrote: > > Hi all, > > > > please review patch for JDK-8204289: AARCH64: enable math intrinsics > > usage in interpreter and C1 > > > > This patch enables usage of math intrinsics for interpreter and C1 in > > case intrinsics are implemented. Code follows that of x86 port. > > > > > > Testing: I've merged this patch with implemented intrinsic and > > launched jtreg tests and benchmark in 2 more modes: -Xint and > > -XX:TieredStopAtLevel=3 > > > > Benchmark scores were improved as expected of intrinsic. All tests > > passed. > > > > > > webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > > > > CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > > > > > > Thanks, > > > > Dmitrij > > From Joshua.Zhu at arm.com Fri Jun 22 06:04:30 2018 From: Joshua.Zhu at arm.com (Joshua Zhu) Date: Fri, 22 Jun 2018 06:04:30 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: <431f6924-b386-c311-9a97-a2c7f146e6c3@bell-sw.com> References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> <431f6924-b386-c311-9a97-a2c7f146e6c3@bell-sw.com> Message-ID: Thank you for review! > -----Original Message----- > From: Dmitrij Pochepko > Sent: Thursday, June 21, 2018 9:25 PM > > On 21.06.2018 16:16, Andrew Haley wrote: > > On 06/21/2018 02:09 PM, Joshua Zhu wrote: > >> I have updated new webrev at > >> http://cr.openjdk.java.net/~zyao/8205004/webrev.03/ > > That looks right. Dmitrij, do you agree it's correct now? > > > Yes. Looks good. From rwestrel at redhat.com Fri Jun 22 07:54:24 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 22 Jun 2018 09:54:24 +0200 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: > webrev: http://cr.openjdk.java.net/~adinn/8204331/webrev.00/ That looks good to me. Roland. From aph at redhat.com Fri Jun 22 08:09:03 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Jun 2018 09:09:03 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: On 06/21/2018 03:20 PM, Andrew Dinn wrote: > There are currently no proper tests for this code as it was difficult to > know how to identify what code gets generated. Detection of failures is > left to asserts in the predicates. That approach has worked in the > present case but only after a breaking change has been pushed and only > by detecting one of several breaking changes. So the current regime is > rather fragile. It would be good to have some jtreg tests to help detect > breakages like this more quickly and effectively. > > A slowdebug build with an available hsdis-aarch64.so could be used to > print out generated assembly. Usefully, in debug mode the C2 back end > will print out block comments indicating both where membars have been > placed and where they have been elided. If a jtreg test was run in an > otherjvm with CompileCommand options to compile and print target methods > then the output could be scanned to look for the relevant membar/membar > elided comments and for presence or absence of ldar/stlr and ldaxr/stlxr > instructions. This would be enough to test that basic transformations > are sound. > > Is it possible to rely on an hsdis library being available in jtreg > tests? Alternatively, is it possible to make execution of the test > conditional on the library being present? Here's an idea: we could scan the generated code. We could also annotate the assembler so that it asserted that all ldar/stlr were generated. We could certainly do that even in a product build. If your tests force C2 compilation and disable inlining we can make the tests repeatable. -- 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 Jun 22 08:26:03 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 22 Jun 2018 10:26:03 +0200 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: > Is it possible to rely on an hsdis library being available in jtreg > tests? Alternatively, is it possible to make execution of the test > conditional on the library being present? What about -XX:+PrintOptoAssembly? It doesn't need hsdis. Roland. From adinn at redhat.com Fri Jun 22 08:30:16 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 22 Jun 2018 09:30:16 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: <75b946c0-44ee-109e-471d-32ba2cdf142e@redhat.com> References: <75b946c0-44ee-109e-471d-32ba2cdf142e@redhat.com> Message-ID: <26eaabda-4b45-d9fa-004d-f23738995799@redhat.com> Hi Roman, On 21/06/18 18:49, Roman Kennke wrote: > thanks so much for fixing this! > > Also, very nice ASCII drawings and explanations! :-) > > As far as I can tell, the patch is good. Ok, thanks for the review. > I'm wondering why it's worth to go through that effort to verify the > correct shape of CAS and similar nodes, and keep maintaining this code > in light of changes (Shenandoah will be the next headache to fix this). > Do the instruction only match those particular shapes, and if it > changes, it'd throw off the matcher badly? I would very much like to find a better, less fragile solution. The problem is finding another way to identify whether or not a Store/Load/CAS needs to translate to acquiring/releasing instructions and (at the same time) whether memory barrier operations in the graph need, respectively, to be elided or generated. The specific, complex graph shapes the predicates test for are indeed unique to volatile operations and so the presence of these shapes enables the former strategy to be adopted. If nodes are found not to be embedded in such a subgraph then they need to be translated via the latter strategy. Perhaps the relevant nodes could be clearly labelled at create time as belonging to a volatile load/store/CAS operation. At present there is no such info in a MemBar node and the memory order property on a load/store node can indicate that it is an ordered operation even when it has not been planted because of a volatile load/store/CAS. The danger here would be losing this info if any nodes were merged or elided by compiler phases although I am not sure that would ever happen. For Graal, I managed to finesse this problem by adding extra graph links from leading membar to Load/Store/CAS to trailing membar. That was easier to do than it is for C2 because in Graal you can annotate links with type tags, indicating that they have a specific semantic. Choosing a special link type makes it possible to avoid breaking the many algorithms which analyze the graph linkage. I don't really know how to achieve that in C2. Roland or Vladimir (take your pick of them ;-) should be in a much better position to address the merits of these two alternatives than I am. 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 Jun 22 08:44:45 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 22 Jun 2018 10:44:45 +0200 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: <26eaabda-4b45-d9fa-004d-f23738995799@redhat.com> References: <75b946c0-44ee-109e-471d-32ba2cdf142e@redhat.com> <26eaabda-4b45-d9fa-004d-f23738995799@redhat.com> Message-ID: > Roland or Vladimir (take your pick of them ;-) should be in a much > better position to address the merits of these two alternatives than I am. Let me take a look. In any case, for JDK 11, I think we should move forward with your fix. Roland. From adinn at redhat.com Fri Jun 22 09:23:24 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 22 Jun 2018 10:23:24 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: <3e26f4e2-9afa-23b6-78e7-65a830de0cc7@redhat.com> On 22/06/18 09:26, Roland Westrelin wrote: >> Is it possible to rely on an hsdis library being available in jtreg >> tests? Alternatively, is it possible to make execution of the test >> conditional on the library being present? > > What about -XX:+PrintOptoAssembly? It doesn't need hsdis. Ah yes, I forgot that was not dependent on hsdis. This would allow us to generate assembler output with comments showing the presence or absence of membars and the appropriate sequence of ld(x)r/st(x)r or lda(x)r or stl(x)r instructions. The test driver could set things up to compile and print a suitable test method in an othervm and check the othervm output to ensure that the membar comments and generated instructions match up. I'll work on implementing a jtreg test based on that but: I'd liek to do that as a follow up to this fix. 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 adinn at redhat.com Fri Jun 22 09:24:50 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 22 Jun 2018 10:24:50 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: <9758cf9b-6388-e73c-532a-4a7cdbf72ff7@redhat.com> On 22/06/18 09:09, Andrew Haley wrote: > Here's an idea: we could scan the generated code. We could also annotate > the assembler so that it asserted that all ldar/stlr were generated. We > could certainly do that even in a product build. If your tests force C2 > compilation and disable inlining we can make the tests repeatable. When you say "we could scan the generated code" the obvious question is: "How?". As in how to do that from a jtreg test? 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 adinn at redhat.com Fri Jun 22 10:52:41 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 22 Jun 2018 11:52:41 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: References: Message-ID: <01d1e054-7ad8-ab0c-905b-eddfdccfced1@redhat.com> On 22/06/18 08:54, Roland Westrelin wrote: > >> webrev: http://cr.openjdk.java.net/~adinn/8204331/webrev.00/ > > That looks good to me. Ok, I pushed the patch with Roman and Roland as reviewers. Roman, enjoy tweaking this to work for Shenandoah :-) 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 dmitrij.pochepko at bell-sw.com Fri Jun 22 12:53:08 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 22 Jun 2018 15:53:08 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Hi Derek, Andrew, Here is an updated version with your comments addressed: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ Thanks, Dmitrij On 22.06.2018 04:40, White, Derek wrote: > Hi Dmitrij, > > There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines > 815, 828, 829, 849, 850. > > I didn't follow all of the differences between the change from call_runtime to __ call_runtime_leaf, (although I see that it follows the x86 code.) So I wouldn't call this a full review. > > Thanks, > - Derek > >> -----Original Message----- >> From: aarch64-port-dev [mailto:aarch64-port-dev- >> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko >> Sent: Wednesday, June 20, 2018 10:45 AM >> To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math >> intrinsics usage in interpreter and C1 >> >> External Email >> >> Hi, >> >> >> can somebody take a look? >> >> >> Thanks, >> >> Dmitrij >> >> >> On 04.06.2018 18:50, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> please review patch for JDK-8204289: AARCH64: enable math intrinsics >>> usage in interpreter and C1 >>> >>> This patch enables usage of math intrinsics for interpreter and C1 in >>> case intrinsics are implemented. Code follows that of x86 port. >>> >>> >>> Testing: I've merged this patch with implemented intrinsic and >>> launched jtreg tests and benchmark in 2 more modes: -Xint and >>> -XX:TieredStopAtLevel=3 >>> >>> Benchmark scores were improved as expected of intrinsic. All tests >>> passed. >>> >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 >>> >>> >>> Thanks, >>> >>> Dmitrij >>> From aph at redhat.com Fri Jun 22 13:40:06 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Jun 2018 14:40:06 +0100 Subject: [aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error In-Reply-To: <9758cf9b-6388-e73c-532a-4a7cdbf72ff7@redhat.com> References: <9758cf9b-6388-e73c-532a-4a7cdbf72ff7@redhat.com> Message-ID: <1bf1f08f-8793-2c37-7974-04d42474a58b@redhat.com> On 06/22/2018 10:24 AM, Andrew Dinn wrote: > On 22/06/18 09:09, Andrew Haley wrote: >> Here's an idea: we could scan the generated code. We could also annotate >> the assembler so that it asserted that all ldar/stlr were generated. We >> could certainly do that even in a product build. If your tests force C2 >> compilation and disable inlining we can make the tests repeatable. > When you say "we could scan the generated code" the obvious question is: > "How?". As in how to do that from a jtreg test? We could add a command-line option to dump the hex. Or even to scan for certain patterns. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Jun 22 16:26:17 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 22 Jun 2018 19:26:17 +0300 Subject: [aarch64-port-dev ] RFR: JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest In-Reply-To: References: <81aa8b38-d1e1-cd44-84cc-3543ce3b08ed@bell-sw.com> <58120f4c-064e-5d8a-7c1d-0b82e756c05f@bell-sw.com> <68f420ff-3956-fd43-c5a3-45e30a5a10dd@redhat.com> <0e82058a-4991-b6f6-274f-9f2ef98b1585@redhat.com> <7a0679de-b3bd-2a6f-a43e-ac2aea876f40@redhat.com> <431f6924-b386-c311-9a97-a2c7f146e6c3@bell-sw.com> Message-ID: pushed. http://hg.openjdk.java.net/jdk/jdk/rev/77fdd64c6334 On 22.06.2018 09:04, Joshua Zhu wrote: > Thank you for review! > >> -----Original Message----- >> From: Dmitrij Pochepko >> Sent: Thursday, June 21, 2018 9:25 PM >> >> On 21.06.2018 16:16, Andrew Haley wrote: >>> On 06/21/2018 02:09 PM, Joshua Zhu wrote: >>>> I have updated new webrev at >>>> http://cr.openjdk.java.net/~zyao/8205004/webrev.03/ >>> That looks right. Dmitrij, do you agree it's correct now? >>> >> Yes. Looks good. From ci_notify at linaro.org Fri Jun 22 21:22:25 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 22 Jun 2018 21:22:25 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <978403997.3213.1529702545739.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/172/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/21 pass: 3,769; fail: 38; error: 5; not run: 11,619 Build 1: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 2: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 3: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 4: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 5: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 6: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 7: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 8: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 Build 10: aarch64/2018/jun/13 pass: 5,674; fail: 24; error: 2; not run: 11,619 Build 11: aarch64/2018/jun/15 pass: 5,674; fail: 23; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/17 pass: 5,698; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/19 pass: 5,698; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/21 pass: 5,700; fail: 23; error: 2; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/21 pass: 8,326; fail: 604; error: 25 Build 1: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 2: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 3: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 4: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 5: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 6: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 7: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 8: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 9: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 Build 10: aarch64/2018/jun/13 pass: 8,435; fail: 576; error: 15 Build 11: aarch64/2018/jun/15 pass: 8,391; fail: 621; error: 16 Build 12: aarch64/2018/jun/17 pass: 8,423; fail: 594; error: 16 Build 13: aarch64/2018/jun/19 pass: 8,433; fail: 583; error: 17 Build 14: aarch64/2018/jun/21 pass: 8,428; fail: 630; error: 18 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/21 pass: 3,867; fail: 6; error: 2 Build 1: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 2: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 3: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 4: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 5: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 6: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 7: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 8: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 9: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 Build 10: aarch64/2018/jun/13 pass: 3,891; fail: 6; error: 2 Build 11: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 12: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 Build 13: aarch64/2018/jun/19 pass: 3,894; fail: 4; error: 5 Build 14: aarch64/2018/jun/21 pass: 3,899; fail: 4; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/21 pass: 3,783; fail: 34; error: 2; not run: 11,619 Build 1: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 2: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 3: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 4: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 5: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 6: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 7: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 8: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 9: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 Build 10: aarch64/2018/jun/13 pass: 5,682; fail: 23; error: 2; not run: 11,619 Build 11: aarch64/2018/jun/15 pass: 5,681; fail: 23; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/17 pass: 5,705; fail: 22; error: 3; not run: 11,619 Build 13: aarch64/2018/jun/19 pass: 5,705; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/21 pass: 5,708; fail: 23; error: 1; not run: 11,619 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/21 pass: 8,363; fail: 578; error: 15 Build 1: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 2: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 3: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 4: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 5: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 6: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 7: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 8: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 9: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 Build 10: aarch64/2018/jun/13 pass: 8,423; fail: 589; error: 15 Build 11: aarch64/2018/jun/15 pass: 8,420; fail: 590; error: 19 Build 12: aarch64/2018/jun/17 pass: 8,436; fail: 581; error: 17 Build 13: aarch64/2018/jun/19 pass: 8,432; fail: 585; error: 17 Build 14: aarch64/2018/jun/21 pass: 8,484; fail: 575; error: 18 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/21 pass: 3,863; fail: 6; error: 6 Build 1: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 2: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 3: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 4: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 5: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 6: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 7: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 8: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 9: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 Build 10: aarch64/2018/jun/13 pass: 3,892; fail: 6; error: 1 Build 11: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 12: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 Build 13: aarch64/2018/jun/19 pass: 3,894; fail: 4; error: 5 Build 14: aarch64/2018/jun/21 pass: 3,902; fail: 4 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): 0.60x Relative performance: Server critical-jOPS (nc): 0.56x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 65.96, Server: 109.42 Client 65.96 / Client 2014-04-01 (43.00): 1.53x Server 109.42 / Server 2014-04-01 (71.00): 1.54x 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 15 days. 2018-05-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/141/results/ 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ 2018-06-15 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/164/results/ 2018-06-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/166/results/ 2018-06-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/168/results/ 2018-06-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/170/results/ 2018-06-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/172/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From dnuechte at amperecomputing.com Sat Jun 23 13:36:18 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Sat, 23 Jun 2018 13:36:18 +0000 Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump Message-ID: I have a very simple maven based JMH test. If I add -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,com.ampere.pipeline_int_mvn.generated.MyBenchmark_test_method_jmhTest::test_method_avgt_jmhStub To my command string, I get a core dump: # Compiler replay data is saved as: # /home/dnuechte/java/pipeline_int_mvn/replay_pid22566.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 22577 Dumping core ... Aborted Should I submit a bug report like the spew suggests? Or is there a different mechanism at this point in the project? I built my own hsdis two different ways, neither works. I built one with binutils 2.24, and one with 2.29. Since there was a change in the interface between 2.24 and 2.29, the version with 2.29 needs a patch to hsdis.c /* Finish linking together the various callback blocks. */ app_data->dinfo.application_data = (void*) app_data; - app_data->dfn = disassembler(native_bfd); + app_data->dfn = disassembler(bfd_get_arch(native_bfd), + bfd_big_endian(native_bfd), + bfd_get_mach(native_bfd), + native_bfd); app_data->dinfo.print_address_func = hsdis_print_address_func; app_data->dinfo.read_memory_func = hsdis_read_memory_func; Dave From dnuechte at amperecomputing.com Sat Jun 23 17:20:37 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Sat, 23 Jun 2018 17:20:37 +0000 Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump In-Reply-To: References: Message-ID: Well, I updated to today's tip, and it no longer core dumps. -----Original Message----- From: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net] On Behalf Of Dave Nuechterlein Sent: Saturday, June 23, 2018 7:36 AM To: aarch64-port-dev at openjdk.java.net Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump I have a very simple maven based JMH test. If I add -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,com.ampere.pipeline_int_mvn.generated.MyBenchmark_test_method_jmhTest::test_method_avgt_jmhStub To my command string, I get a core dump: # Compiler replay data is saved as: # /home/dnuechte/java/pipeline_int_mvn/replay_pid22566.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 22577 Dumping core ... Aborted Should I submit a bug report like the spew suggests? Or is there a different mechanism at this point in the project? I built my own hsdis two different ways, neither works. I built one with binutils 2.24, and one with 2.29. Since there was a change in the interface between 2.24 and 2.29, the version with 2.29 needs a patch to hsdis.c /* Finish linking together the various callback blocks. */ app_data->dinfo.application_data = (void*) app_data; - app_data->dfn = disassembler(native_bfd); + app_data->dfn = disassembler(bfd_get_arch(native_bfd), + bfd_big_endian(native_bfd), + bfd_get_mach(native_bfd), + native_bfd); app_data->dinfo.print_address_func = hsdis_print_address_func; app_data->dinfo.read_memory_func = hsdis_read_memory_func; Dave From aph at redhat.com Sun Jun 24 07:44:46 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 24 Jun 2018 08:44:46 +0100 Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump In-Reply-To: References: Message-ID: <8ac6c027-f589-29c7-850f-a4c784c7d2c8@redhat.com> On 06/23/2018 02:36 PM, Dave Nuechterlein wrote: > I have a very simple maven based JMH test. If I add > -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,com.ampere.pipeline_int_mvn.generated.MyBenchmark_test_method_jmhTest::test_method_avgt_jmhStub > To my command string, I get a core dump: > > # Compiler replay data is saved as: > # /home/dnuechte/java/pipeline_int_mvn/replay_pid22566.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Current thread is 22577 > Dumping core ... > Aborted > > Should I submit a bug report like the spew suggests? Or is there a different mechanism at this point in the project? No, just send the info to this list. > I built my own hsdis two different ways, neither works. I built one with binutils 2.24, and one with 2.29. Since there was a change in the interface between 2.24 and 2.29, the version with 2.29 needs a patch to hsdis.c > > /* Finish linking together the various callback blocks. */ > app_data->dinfo.application_data = (void*) app_data; > - app_data->dfn = disassembler(native_bfd); > + app_data->dfn = disassembler(bfd_get_arch(native_bfd), > + bfd_big_endian(native_bfd), > + bfd_get_mach(native_bfd), > + native_bfd); > app_data->dinfo.print_address_func = hsdis_print_address_func; > app_data->dinfo.read_memory_func = hsdis_read_memory_func; I have no idea: my hsdis works just fine. In what way doesn't it work? -- 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 Sun Jun 24 07:46:08 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 24 Jun 2018 08:46:08 +0100 Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump In-Reply-To: References: Message-ID: On 06/23/2018 06:20 PM, Dave Nuechterlein wrote: > Well, I updated to today's tip, and it no longer core dumps. changeset: 50713:9894c4d30168 user: adinn date: Fri Jun 22 11:21:34 2018 +0100 summary: 8204331: AArch64: fix CAS not embedded in normal graph error -- 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 Sun Jun 24 12:06:07 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 24 Jun 2018 15:06:07 +0300 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> Message-ID: <1c324f0a-03c4-a02c-7688-43b5ad4257bc@samersoff.net> Dmitrij, Looks good to me. -Dmitry On 06/21/2018 06:30 PM, Dmitrij Pochepko wrote: > Hi, > > I need official reviewer to review this version together with "8204289: > AARCH64: enable math intrinsics usage in interpreter and C1" to wrap > this up. > > Thanks, > > Dmitrij > > > On 20.06.2018 19:51, White, Derek wrote: >> Hi Dmitrij, >> >> Looks good to me. Thanks! >> - Derek >> >>> -----Original Message----- >>> From: Dmitrij Pochepko [mailto:dmitrij.pochepko at bell-sw.com] >>> Sent: Wednesday, June 20, 2018 10:26 AM >>> To: Andrew Haley ; White, Derek >>> >>> Cc: aarch64-port-dev at openjdk.java.net >>> Subject: Re: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create >>> intrinsic >>> for Math.log >>> >>> External Email >>> >>> Hi, >>> >>> >>> On 20.06.2018 11:31, Andrew Haley wrote: >>>> On 06/20/2018 12:45 AM, White, Derek wrote: >>>>> ?? - Line 68: Could align to 64 bytes. We're going to load the >>>>> first 64 bytes, >>> may as well use one cache line. >>> Agree. It'll be a bit better to use 64 bytes alignment. I changed it to >>> 64 and tested the revised patch. I could not see a difference in >>> synthetic >>> benchmark, but single invocation might gain a small difference in >>> case of L1 >>> miss. >>>>> ?? - Lines 71, 77, 79. You could comment these lines with "_coeff", >>>>> "_log2", >>> and "_L_tbl", for clearer correspondence to x86 code. >>> Added respective comment. >>>>> - Line 204: I believe that we should be looking for equal to 0.0: >>>>> 204 //????? if (X = 0.0d) return -INFINITY; >>>> Yes.? if (X == 0.0d). >>> Thank you for noticing this typo. Assembly is correct. I fixed this >>> comment. >>>>> - The (float)(zeroExponent(X) code was fun. >>>>> >>>>> - Are there any concerns about denormalized inputs? I didn't see any >>> obvious problem in the code pulling aaprt and adding in exponents, but >>> there's nothing obvious in that code to me. >>>> IEEE denormals don't usually require any special handling. >>> There is no denormals-specific code in this algorithm. >>>>> - The RETURN_MINF_OR_NAN block can generate a wide range of >>> signaling and non-signaling NaNs. I forget how signaling Nans are >>> treated in >>> the Java math mode - are they just treated as quiet NaNs or are they >>> never >>> supposed to appear? >>>> Java doesn't care.? However, it is possible to use DoubleToRawLongBits >>>> to extract some information, and this is fine. >>> I also aligned comments as in sin/cos patch and fixed the copyright. >>> >>> Here, the original code has table in HEX and also the article has HEX >>> representation, so I kept HEX in the table. >>> >>> Please take a look at updated webrev: >>> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ >>> >>> Thanks, >>> Dmitrij > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dms at samersoff.net Sun Jun 24 12:17:02 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 24 Jun 2018 15:17:02 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Dmitrij, Looks good to me. We may consider to create a macros for the pattern like one below sometimes in a future. 285 if (StubRoutines::dexp() == NULL) { 286 fn = CAST_FROM_FN_PTR(address, SharedRuntime::dexp); 287 } else { 288 fn = CAST_FROM_FN_PTR(address, StubRoutines::dexp()); 289 } -Dmitry On 06/22/2018 03:53 PM, Dmitrij Pochepko wrote: > Hi Derek, Andrew, > > Here is an updated version with your comments addressed: > http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ > > Thanks, > > Dmitrij > > > On 22.06.2018 04:40, White, Derek wrote: >> Hi Dmitrij, >> >> There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines >> 815, 828, 829, 849, 850. >> >> I didn't follow all of the differences between the change from >> call_runtime to __ call_runtime_leaf, (although I see that it follows >> the x86 code.) So I wouldn't call this a full review. >> >> Thanks, >> - Derek >> >>> -----Original Message----- >>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko >>> Sent: Wednesday, June 20, 2018 10:45 AM >>> To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- >>> dev at openjdk.java.net >>> Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math >>> intrinsics usage in interpreter and C1 >>> >>> External Email >>> >>> Hi, >>> >>> >>> can somebody take a look? >>> >>> >>> Thanks, >>> >>> Dmitrij >>> >>> >>> On 04.06.2018 18:50, Dmitrij Pochepko wrote: >>>> Hi all, >>>> >>>> please review patch for JDK-8204289: AARCH64: enable math intrinsics >>>> usage in interpreter and C1 >>>> >>>> This patch enables usage of math intrinsics for interpreter and C1 in >>>> case intrinsics are implemented. Code follows that of x86 port. >>>> >>>> >>>> Testing: I've merged this patch with implemented intrinsic and >>>> launched jtreg tests and benchmark in 2 more modes: -Xint and >>>> -XX:TieredStopAtLevel=3 >>>> >>>> Benchmark scores were improved as expected of intrinsic. All tests >>>> passed. >>>> >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 >>>> >>>> >>>> Thanks, >>>> >>>> Dmitrij >>>> > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dnuechte at amperecomputing.com Sun Jun 24 15:02:48 2018 From: dnuechte at amperecomputing.com (Dave Nuechterlein) Date: Sun, 24 Jun 2018 15:02:48 +0000 Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump In-Reply-To: References: Message-ID: I have no idea is it was hsdis, jvm itself, or the interface between the two. Apparently, it was the JVM itself. -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Sunday, June 24, 2018 1:46 AM To: Dave Nuechterlein ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump On 06/23/2018 06:20 PM, Dave Nuechterlein wrote: > Well, I updated to today's tip, and it no longer core dumps. changeset: 50713:9894c4d30168 user: adinn date: Fri Jun 22 11:21:34 2018 +0100 summary: 8204331: AArch64: fix CAS not embedded in normal graph error -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Sun Jun 24 20:00:43 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 24 Jun 2018 20:00:43 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <323324808.3385.1529870444038.JavaMail.jenkins@b5e45f3bc652> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2018/174/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/23 pass: 3,868; fail: 37; error: 4; not run: 11,619 Build 1: aarch64/2018/may/25 pass: 5,209; fail: 45; error: 3; not run: 11,619 Build 2: aarch64/2018/may/27 pass: 5,210; fail: 43; error: 4; not run: 11,619 Build 3: aarch64/2018/may/29 pass: 5,209; fail: 44; error: 4; not run: 11,619 Build 4: aarch64/2018/jun/03 pass: 5,640; fail: 24; error: 5; not run: 11,619 Build 5: aarch64/2018/jun/05 pass: 5,642; fail: 25; error: 3; not run: 11,619 Build 6: aarch64/2018/jun/07 pass: 5,640; fail: 26; error: 4; not run: 11,619 Build 7: aarch64/2018/jun/09 pass: 5,654; fail: 25; error: 3; not run: 11,619 Build 8: aarch64/2018/jun/11 pass: 5,653; fail: 26; error: 3; not run: 11,619 Build 9: aarch64/2018/jun/13 pass: 5,674; fail: 24; error: 2; not run: 11,619 Build 10: aarch64/2018/jun/15 pass: 5,674; fail: 23; error: 2; not run: 11,619 Build 11: aarch64/2018/jun/17 pass: 5,698; fail: 23; error: 2; not run: 11,619 Build 12: aarch64/2018/jun/19 pass: 5,698; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/21 pass: 5,700; fail: 23; error: 2; not run: 11,619 Build 14: aarch64/2018/jun/23 pass: 5,701; fail: 24; error: 1; not run: 11,619 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/23 pass: 8,328; fail: 610; error: 24 Build 1: aarch64/2018/may/25 pass: 8,302; fail: 638; error: 23 Build 2: aarch64/2018/may/27 pass: 8,331; fail: 611; error: 23 Build 3: aarch64/2018/may/29 pass: 8,320; fail: 616; error: 29 Build 4: aarch64/2018/jun/03 pass: 8,362; fail: 629; error: 25 Build 5: aarch64/2018/jun/05 pass: 8,395; fail: 599; error: 23 Build 6: aarch64/2018/jun/07 pass: 8,384; fail: 612; error: 24 Build 7: aarch64/2018/jun/09 pass: 8,388; fail: 614; error: 22 Build 8: aarch64/2018/jun/11 pass: 8,399; fail: 601; error: 24 Build 9: aarch64/2018/jun/13 pass: 8,435; fail: 576; error: 15 Build 10: aarch64/2018/jun/15 pass: 8,391; fail: 621; error: 16 Build 11: aarch64/2018/jun/17 pass: 8,423; fail: 594; error: 16 Build 12: aarch64/2018/jun/19 pass: 8,433; fail: 583; error: 17 Build 13: aarch64/2018/jun/21 pass: 8,428; fail: 630; error: 18 Build 14: aarch64/2018/jun/23 pass: 8,434; fail: 627; error: 20 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/23 pass: 3,871; fail: 6; error: 3 Build 1: aarch64/2018/may/25 pass: 3,877; fail: 6; error: 5 Build 2: aarch64/2018/may/27 pass: 3,880; fail: 6; error: 2 Build 3: aarch64/2018/may/29 pass: 3,879; fail: 6; error: 4 Build 4: aarch64/2018/jun/03 pass: 3,882; fail: 6; error: 3 Build 5: aarch64/2018/jun/05 pass: 3,884; fail: 6; error: 4 Build 6: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 7: aarch64/2018/jun/09 pass: 3,887; fail: 6; error: 5 Build 8: aarch64/2018/jun/11 pass: 3,887; fail: 6; error: 5 Build 9: aarch64/2018/jun/13 pass: 3,891; fail: 6; error: 2 Build 10: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 11: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 Build 12: aarch64/2018/jun/19 pass: 3,894; fail: 4; error: 5 Build 13: aarch64/2018/jun/21 pass: 3,899; fail: 4; error: 3 Build 14: aarch64/2018/jun/23 pass: 3,902; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/23 pass: 3,879; fail: 34; error: 3; not run: 11,619 Build 1: aarch64/2018/may/25 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 2: aarch64/2018/may/27 pass: 5,220; fail: 40; error: 4; not run: 11,619 Build 3: aarch64/2018/may/29 pass: 5,219; fail: 42; error: 3; not run: 11,619 Build 4: aarch64/2018/jun/03 pass: 5,651; fail: 22; error: 3; not run: 11,619 Build 5: aarch64/2018/jun/05 pass: 5,651; fail: 23; error: 3; not run: 11,619 Build 6: aarch64/2018/jun/07 pass: 5,650; fail: 24; error: 3; not run: 11,619 Build 7: aarch64/2018/jun/09 pass: 5,663; fail: 24; error: 2; not run: 11,619 Build 8: aarch64/2018/jun/11 pass: 5,664; fail: 23; error: 2; not run: 11,619 Build 9: aarch64/2018/jun/13 pass: 5,682; fail: 23; error: 2; not run: 11,619 Build 10: aarch64/2018/jun/15 pass: 5,681; fail: 23; error: 2; not run: 11,619 Build 11: aarch64/2018/jun/17 pass: 5,705; fail: 22; error: 3; not run: 11,619 Build 12: aarch64/2018/jun/19 pass: 5,705; fail: 23; error: 2; not run: 11,619 Build 13: aarch64/2018/jun/21 pass: 5,708; fail: 23; error: 1; not run: 11,619 Build 14: aarch64/2018/jun/23 pass: 5,707; fail: 25; error: 1; not run: 11,619 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/23 pass: 8,361; fail: 583; error: 19 Build 1: aarch64/2018/may/25 pass: 8,357; fail: 591; error: 16 Build 2: aarch64/2018/may/27 pass: 8,359; fail: 589; error: 18 Build 3: aarch64/2018/may/29 pass: 8,372; fail: 576; error: 18 Build 4: aarch64/2018/jun/03 pass: 8,379; fail: 618; error: 20 Build 5: aarch64/2018/jun/05 pass: 8,415; fail: 586; error: 17 Build 6: aarch64/2018/jun/07 pass: 8,382; fail: 622; error: 17 Build 7: aarch64/2018/jun/09 pass: 8,425; fail: 584; error: 16 Build 8: aarch64/2018/jun/11 pass: 8,416; fail: 592; error: 17 Build 9: aarch64/2018/jun/13 pass: 8,423; fail: 589; error: 15 Build 10: aarch64/2018/jun/15 pass: 8,420; fail: 590; error: 19 Build 11: aarch64/2018/jun/17 pass: 8,436; fail: 581; error: 17 Build 12: aarch64/2018/jun/19 pass: 8,432; fail: 585; error: 17 Build 13: aarch64/2018/jun/21 pass: 8,484; fail: 575; error: 18 Build 14: aarch64/2018/jun/23 pass: 8,454; fail: 613; error: 15 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/may/23 pass: 3,867; fail: 6; error: 7 Build 1: aarch64/2018/may/25 pass: 3,878; fail: 6; error: 4 Build 2: aarch64/2018/may/27 pass: 3,877; fail: 6; error: 5 Build 3: aarch64/2018/may/29 pass: 3,877; fail: 6; error: 6 Build 4: aarch64/2018/jun/03 pass: 3,884; fail: 6; error: 1 Build 5: aarch64/2018/jun/05 pass: 3,885; fail: 6; error: 3 Build 6: aarch64/2018/jun/07 pass: 3,887; fail: 6; error: 3 Build 7: aarch64/2018/jun/09 pass: 3,888; fail: 6; error: 4 Build 8: aarch64/2018/jun/11 pass: 3,886; fail: 6; error: 6 Build 9: aarch64/2018/jun/13 pass: 3,892; fail: 6; error: 1 Build 10: aarch64/2018/jun/15 pass: 3,894; fail: 4; error: 4 Build 11: aarch64/2018/jun/17 pass: 3,893; fail: 4; error: 5 Build 12: aarch64/2018/jun/19 pass: 3,894; fail: 4; error: 5 Build 13: aarch64/2018/jun/21 pass: 3,902; fail: 4 Build 14: aarch64/2018/jun/23 pass: 3,902; fail: 4 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): 1.00x Relative performance: Server critical-jOPS (nc): 0.88x 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 client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 68.52, Server: 116.65 Client 68.52 / Client 2014-04-01 (43.00): 1.59x Server 116.65 / Server 2014-04-01 (71.00): 1.64x 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 15 days. 2018-05-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/143/results/ 2018-05-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/145/results/ 2018-05-28 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/147/results/ 2018-05-31 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/149/results/ 2018-06-04 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/154/results/ 2018-06-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/156/results/ 2018-06-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/158/results/ 2018-06-10 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/160/results/ 2018-06-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/162/results/ 2018-06-15 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/164/results/ 2018-06-17 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/166/results/ 2018-06-19 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/168/results/ 2018-06-21 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/170/results/ 2018-06-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/172/results/ 2018-06-24 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/174/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Derek.White at cavium.com Mon Jun 25 03:39:26 2018 From: Derek.White at cavium.com (White, Derek) Date: Mon, 25 Jun 2018 03:39:26 +0000 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: Hi Dmitrij, So it looks like fixing it this way means that when InlineMathNatives is set false, then it disables these intrinsics in C1, C2 and interpreter? Looks good! - Derek > -----Original Message----- > From: Dmitrij Pochepko [mailto:dmitrij.pochepko at bell-sw.com] > Sent: Friday, June 22, 2018 8:53 AM > To: White, Derek ; Andrew Haley > > Cc: aarch64-port-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math > intrinsics usage in interpreter and C1 > > External Email > > Hi Derek, Andrew, > > Here is an updated version with your comments addressed: > http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ > > Thanks, > > Dmitrij > > > On 22.06.2018 04:40, White, Derek wrote: > > Hi Dmitrij, > > > > There's some bad indenting in c1_LIRGenerator_aarch64.cpp around lines > > 815, 828, 829, 849, 850. > > > > I didn't follow all of the differences between the change from call_runtime > to __ call_runtime_leaf, (although I see that it follows the x86 code.) So I > wouldn't call this a full review. > > > > Thanks, > > - Derek > > > >> -----Original Message----- > >> From: aarch64-port-dev [mailto:aarch64-port-dev- > >> bounces at openjdk.java.net] On Behalf Of Dmitrij Pochepko > >> Sent: Wednesday, June 20, 2018 10:45 AM > >> To: aarch64-port-dev at openjdk.java.net; hotspot-compiler- > >> dev at openjdk.java.net > >> Subject: Re: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math > >> intrinsics usage in interpreter and C1 > >> > >> External Email > >> > >> Hi, > >> > >> > >> can somebody take a look? > >> > >> > >> Thanks, > >> > >> Dmitrij > >> > >> > >> On 04.06.2018 18:50, Dmitrij Pochepko wrote: > >>> Hi all, > >>> > >>> please review patch for JDK-8204289: AARCH64: enable math intrinsics > >>> usage in interpreter and C1 > >>> > >>> This patch enables usage of math intrinsics for interpreter and C1 > >>> in case intrinsics are implemented. Code follows that of x86 port. > >>> > >>> > >>> Testing: I've merged this patch with implemented intrinsic and > >>> launched jtreg tests and benchmark in 2 more modes: -Xint and > >>> -XX:TieredStopAtLevel=3 > >>> > >>> Benchmark scores were improved as expected of intrinsic. All tests > >>> passed. > >>> > >>> > >>> webrev: http://cr.openjdk.java.net/~dpochepk/8204289/webrev.01/ > >>> > >>> CR: https://bugs.openjdk.java.net/browse/JDK-8204289 > >>> > >>> > >>> Thanks, > >>> > >>> Dmitrij > >>> From aph at redhat.com Mon Jun 25 07:10:24 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 08:10:24 +0100 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> Message-ID: <1d82da14-f1f5-1629-065f-dd091b2346e3@redhat.com> On 06/22/2018 01:53 PM, Dmitrij Pochepko wrote: > Here is an updated version with your comments addressed: > http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ OK, we're 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 Mon Jun 25 07:18:48 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 08:18:48 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> Message-ID: <24cf3572-e2c8-6419-9c81-1da0e283b20a@redhat.com> On 06/20/2018 03:26 PM, Dmitrij Pochepko wrote: > Here, the original code has table in HEX and also the article has HEX > representation, so I kept HEX in the table. > > Please take a look at updated webrev: > http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ Looks 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 Mon Jun 25 07:32:15 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 08:32:15 +0100 Subject: [aarch64-port-dev ] RFR(M): 8196402: AARCH64: create intrinsic for Math.log In-Reply-To: <24cf3572-e2c8-6419-9c81-1da0e283b20a@redhat.com> References: <296818a4-2e9c-6e60-70b3-cd5a52e49cb1@bell-sw.com> <87f69722-0a1f-dfbc-e6a5-10ea7c0bbd4b@redhat.com> <5dbf89dd-fc06-8a36-039a-7b5a18178050@bell-sw.com> <12856099-ecfb-c77b-dcc6-c57b5b3dbf72@bell-sw.com> <55835b6e-844c-c858-1c73-8609d155a619@redhat.com> <2f1a75b8-717c-c7ee-214a-70644e54012b@redhat.com> <51f95a09-9bc0-0be5-8302-4a797e31e029@bell-sw.com> <24cf3572-e2c8-6419-9c81-1da0e283b20a@redhat.com> Message-ID: On 06/25/2018 08:18 AM, Andrew Haley wrote: > On 06/20/2018 03:26 PM, Dmitrij Pochepko wrote: >> Here, the original code has table in HEX and also the article has HEX >> representation, so I kept HEX in the table. >> >> Please take a look at updated webrev: >> http://cr.openjdk.java.net/~dpochepk/8196402/webrev.06/ > > Looks good. Thanks. > This should have gone to hotspot-dev too. -- 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 Jun 25 08:08:12 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 25 Jun 2018 09:08:12 +0100 Subject: [aarch64-port-dev ] -XX:CompileCommand=print causes core dump In-Reply-To: References: Message-ID: <0e21426c-03a5-7829-bc63-c9c917d4fdde@redhat.com> Hi Dave, On 24/06/18 16:02, Dave Nuechterlein wrote: > I have no idea is it was hsdis, jvm itself, or the interface between > the two. Apparently, it was the JVM itself. The checkin Andrew pointed out in his reply (see below) was the fix which corrected generation of code for volatile store/CAS that I mentioned I was working on last week. Without this fix you may well have seen weird behaviour because of incorrect code generation. The assert which caught the problem only applies to debug builds and only for the CAS case. 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 > -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] > Sent: Sunday, June 24, 2018 1:46 AM To: Dave Nuechterlein > ; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] -XX:CompileCommand=print causes core > dump > > On 06/23/2018 06:20 PM, Dave Nuechterlein wrote: >> Well, I updated to today's tip, and it no longer core dumps. > > changeset: 50713:9894c4d30168 user: adinn date: Fri > Jun 22 11:21:34 2018 +0100 summary: 8204331: AArch64: fix CAS not > embedded in normal graph error From dmitrij.pochepko at bell-sw.com Mon Jun 25 09:45:21 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 12:45:21 +0300 Subject: [aarch64-port-dev ] RFR: 8204289: AARCH64: enable math intrinsics usage in interpreter and C1 In-Reply-To: <1d82da14-f1f5-1629-065f-dd091b2346e3@redhat.com> References: <6bd4bccb-befb-0523-d75e-2c5a99c4ee34@bell-sw.com> <6e1457db-9b5c-3bbd-65fc-ebd2a9e99558@bell-sw.com> <1d82da14-f1f5-1629-065f-dd091b2346e3@redhat.com> Message-ID: Dmitry, Derek, Andrew, Thank you for review! On 25.06.2018 10:10, Andrew Haley wrote: > On 06/22/2018 01:53 PM, Dmitrij Pochepko wrote: >> Here is an updated version with your comments addressed: >> http://cr.openjdk.java.net/~dpochepk/8204289/webrev.03/ > OK, we're good. Thanks. > From dmitrij.pochepko at bell-sw.com Mon Jun 25 14:53:41 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 17:53:41 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp Message-ID: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Hi all, please review patch for 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp This patch replaces ldpd/stpd instructions with ld1/st1 for saving/restoring registers in C1_Runtime1_aarch64.cpp which is more compact and more beneficial for a number of stubs. webrev: http://cr.openjdk.java.net/~dpochepk/8205475/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8205475 Testing: hotspot jtreg test in fastdebug and release builds. example: ? 0x0000ffff88b23468: ldp?????? d0, d1, [sp], #16 ? 0x0000ffff88b2346c: ldp?????? d2, d3, [sp], #16 ? 0x0000ffff88b23470: ldp?????? d4, d5, [sp], #16 ? 0x0000ffff88b23474: ldp?????? d6, d7, [sp], #16 ? 0x0000ffff88b23478: ldp?????? d8, d9, [sp], #16 ? 0x0000ffff88b2347c: ldp?????? d10, d11, [sp], #16 ? 0x0000ffff88b23480: ldp?????? d12, d13, [sp], #16 ? 0x0000ffff88b23484: ldp?????? d14, d15, [sp], #16 ? 0x0000ffff88b23488: ldp?????? d16, d17, [sp], #16 ? 0x0000ffff88b2348c: ldp?????? d18, d19, [sp], #16 ? 0x0000ffff88b23490: ldp?????? d20, d21, [sp], #16 ? 0x0000ffff88b23494: ldp?????? d22, d23, [sp], #16 ? 0x0000ffff88b23498: ldp?????? d24, d25, [sp], #16 ? 0x0000ffff88b2349c: ldp?????? d26, d27, [sp], #16 ? 0x0000ffff88b234a0: ldp?????? d28, d29, [sp], #16 ? 0x0000ffff88b234a4: ldp?????? d30, d31, [sp], #16 changed to: ? 0x0000ffff9cb23468: ld1?????? {v0.1d-v3.1d}, [sp], #32 ? 0x0000ffff9cb2346c: ld1?????? {v4.1d-v7.1d}, [sp], #32 ? 0x0000ffff9cb23470: ld1?????? {v8.1d-v11.1d}, [sp], #32 ? 0x0000ffff9cb23474: ld1?????? {v12.1d-v15.1d}, [sp], #32 ? 0x0000ffff9cb23478: ld1?????? {v16.1d-v19.1d}, [sp], #32 ? 0x0000ffff9cb2347c: ld1?????? {v20.1d-v23.1d}, [sp], #32 ? 0x0000ffff9cb23480: ld1?????? {v24.1d-v27.1d}, [sp], #32 ? 0x0000ffff9cb23484: ld1?????? {v28.1d-v31.1d}, [sp], #32 Thanks, Dmitrij From aph at redhat.com Mon Jun 25 15:08:08 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Jun 2018 16:08:08 +0100 Subject: [aarch64-port-dev ] RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Message-ID: <6720d2b7-620c-a7b8-c1c1-e377e9e1332d@redhat.com> On 06/25/2018 03:53 PM, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8205475/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8205475 OK, that looks fine. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Mon Jun 25 15:34:02 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 18:34:02 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: <6720d2b7-620c-a7b8-c1c1-e377e9e1332d@redhat.com> References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> <6720d2b7-620c-a7b8-c1c1-e377e9e1332d@redhat.com> Message-ID: <1361e806-17ec-16bb-d915-1e0dfdab624a@bell-sw.com> Thank you for review! On 25.06.2018 18:08, Andrew Haley wrote: > On 06/25/2018 03:53 PM, Dmitrij Pochepko wrote: >> webrev: http://cr.openjdk.java.net/~dpochepk/8205475/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8205475 > OK, that looks fine. > From adinn at redhat.com Mon Jun 25 15:43:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 25 Jun 2018 16:43:37 +0100 Subject: [aarch64-port-dev ] RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Message-ID: On 25/06/18 15:53, Dmitrij Pochepko wrote: > please review patch for 8205475 - AARCH64: optimize FPU loads and stores > in C1_Runtime1_aarch64.cpp 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 dmitrij.pochepko at bell-sw.com Mon Jun 25 17:28:52 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 25 Jun 2018 20:28:52 +0300 Subject: [aarch64-port-dev ] RFR(S): 8205475 - AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp In-Reply-To: References: <381edc4e-a686-31b5-e26f-593d26bc2683@bell-sw.com> Message-ID: Thank you for review! On 25.06.2018 18:43, Andrew Dinn wrote: > On 25/06/18 15:53, Dmitrij Pochepko wrote: >> please review patch for 8205475 - AARCH64: optimize FPU loads and stores >> in C1_Runtime1_aarch64.cpp > 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 stuart.monteith at linaro.org Tue Jun 26 13:42:59 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 26 Jun 2018 14:42:59 +0100 Subject: [aarch64-port-dev ] 64-Bit literal oops Message-ID: Hello, As requested, I've gotten what is appears to be near the minimal set of changes for 64-bit literal oops. We really only need this for ZGC, so apart from testing, it would only be ZGC enabling it. Otherwise, there are no other interesting uses, apart from maybe as support for 52-bit addressing. I've tested with movz, movk, movk, possible movk patching in MacroAssembler::pd_patch_instruction_size and MacroAssembler::target_addr_for_insn . The "ShouldNotReachHere()" calls are never tripped, and so could be taken out. I'm pushing down a flag from movoop down to movptr, to indicate when an oop literal is being emitted, which movoop obviously implicitly knows: MacroAssembler::movoop(Register, jobject, bool) MacroAssembler:mov(Register, Address, bool isOop) MacroAssembler:movptr(Register, u_int64_t, bool isOop) NativeMovConstReg has been changed to detect the size of the instruction - as it may be a movz,movk,movk combination, or perhaps it will be an oop with an additional movk for the 64-bit literal oop. It does this conditionally. I have been considering adding an additional check by comparing the register being stored to. I'm looking now at adding information to relocs to indicate they are for an oop, as suggested by aph. BR, Stuart From adinn at redhat.com Tue Jun 26 16:55:42 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 26 Jun 2018 17:55:42 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation Message-ID: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Reviews are welcome for the following webrev webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 The patch: ---------- This AArch64-only patch adds tests to ensure that volatile load, store and CAS operations are either: translated to correctly replace memory barriers with combinations of acquiring loads and releasing left untransformed with all necessary memory barriers in place The test requires a debug, aarch64 vm and is disabled if graal is being used (debug is necessary because it relies on -XX:+PrintOptoAssembly to provide evidence of what is in the compiler output). The main driver test program creates subordinate JVMs to execute subordinate programs which perform: normal and unsafe volatile loads, normal and unsafe volatile stores unsafe volatile CASes in each of 5 GC configurations: G1 CMS+CondCardMark CMS-CondCardMark Parallel Serial Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are used to generate Assembly listings and the driver test program parses these to ensure the correct sequences of instructions are generated (including omitted memory barriers which are flagged in the output). A few changes were made to the aarch64.ad file to ensure that the PrintOptoAssembly output accurately represented the generated code. These were necessary to ensure that the test could be sure that the generated code sequences really were what was intended. Also, some of the comments in aarch64.ad describing the code transformation were updated following feedback from Zhongwei Yao that arrived too late to get checked in with the fix for JDK-8204331. Testing: -------- The test itself passes when run on an AArch64 debug vm. It is ignored when run on an AArch64 product vm. No other testing is needed. Nothing significant in the aarch64.ad file has been modified (only comments of format sequences which have been exercised running the new test). 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 Jun 26 17:10:54 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jun 2018 18:10:54 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <5c631885-8516-1aad-b978-596aa32209c6@redhat.com> On 06/26/2018 05:55 PM, Andrew Dinn wrote: > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 Yowza. OK, so that wasn't a proper review. This looks great, and pretty thorough. I'm sure there are still some ways in which the logic might fail and not be caught, but this should get the obvious ones. I don't much like the assert() rathern than guarantee() for the failures in C2. Won't we just crash anyway if these asserts fail? If so, we might as well use guarantee(). -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Tue Jun 26 17:23:12 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jun 2018 10:23:12 -0700 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi Andrew, Small note - all files should have Copyright header. I see only main test file have one. Thanks, Vladimir On 6/26/18 9:55 AM, Andrew Dinn wrote: > Reviews are welcome for the following webrev > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > The patch: > ---------- > > This AArch64-only patch adds tests to ensure that volatile load, store > and CAS operations are either: > > translated to correctly replace memory barriers with combinations of > acquiring loads and releasing > > left untransformed with all necessary memory barriers in place > > The test requires a debug, aarch64 vm and is disabled if graal is being > used (debug is necessary because it relies on -XX:+PrintOptoAssembly to > provide evidence of what is in the compiler output). > > The main driver test program creates subordinate JVMs to execute > subordinate programs which perform: > > normal and unsafe volatile loads, > normal and unsafe volatile stores > unsafe volatile CASes > > in each of 5 GC configurations: > > G1 > CMS+CondCardMark > CMS-CondCardMark > Parallel > Serial > > Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are > used to generate Assembly listings and the driver test program parses > these to ensure the correct sequences of instructions are generated > (including omitted memory barriers which are flagged in the output). > > A few changes were made to the aarch64.ad file to ensure that the > PrintOptoAssembly output accurately represented the generated code. > These were necessary to ensure that the test could be sure that the > generated code sequences really were what was intended. > > Also, some of the comments in aarch64.ad describing the code > transformation were updated following feedback from Zhongwei Yao that > arrived too late to get checked in with the fix for JDK-8204331. > > Testing: > -------- > > The test itself passes when run on an AArch64 debug vm. It is ignored > when run on an AArch64 product vm. > > No other testing is needed. Nothing significant in the aarch64.ad file > has been modified (only comments of format sequences which have been > exercised running the new test). > > 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 dmitrij.pochepko at bell-sw.com Tue Jun 26 18:33:40 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 26 Jun 2018 21:33:40 +0300 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi Andrew, Overall looks good, but I have few minor comments regarding these tests: 1. Most tests which spawn other precesses for testing purposes are launched as "@run driver ..." for optimization reasons. 2. Do we really need to ignore external vm options set in jtreg via option: -javaoptions:""? In case these tests shouldn't ignore external options, there is ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, String... command) for that. 3. This test will fail if jdk will be built without all GCs or without C2. It probably a good idea to split it in few tests with separate GC configurations 4. In case external options are not ignored, you'll need to filter out several vm options, like skipping execution for c1 or interpreter testruns. Something like this can be added: @requires vm.compMode != "Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | vm.opt.TieredStopAtLevel==4) Thanks, Dmitrij On 26.06.2018 19:55, Andrew Dinn wrote: > Reviews are welcome for the following webrev > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > The patch: > ---------- > > This AArch64-only patch adds tests to ensure that volatile load, store > and CAS operations are either: > > translated to correctly replace memory barriers with combinations of > acquiring loads and releasing > > left untransformed with all necessary memory barriers in place > > The test requires a debug, aarch64 vm and is disabled if graal is being > used (debug is necessary because it relies on -XX:+PrintOptoAssembly to > provide evidence of what is in the compiler output). > > The main driver test program creates subordinate JVMs to execute > subordinate programs which perform: > > normal and unsafe volatile loads, > normal and unsafe volatile stores > unsafe volatile CASes > > in each of 5 GC configurations: > > G1 > CMS+CondCardMark > CMS-CondCardMark > Parallel > Serial > > Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are > used to generate Assembly listings and the driver test program parses > these to ensure the correct sequences of instructions are generated > (including omitted memory barriers which are flagged in the output). > > A few changes were made to the aarch64.ad file to ensure that the > PrintOptoAssembly output accurately represented the generated code. > These were necessary to ensure that the test could be sure that the > generated code sequences really were what was intended. > > Also, some of the comments in aarch64.ad describing the code > transformation were updated following feedback from Zhongwei Yao that > arrived too late to get checked in with the fix for JDK-8204331. > > Testing: > -------- > > The test itself passes when run on an AArch64 debug vm. It is ignored > when run on an AArch64 product vm. > > No other testing is needed. Nothing significant in the aarch64.ad file > has been modified (only comments of format sequences which have been > exercised running the new test). > > 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 Zhongwei.Yao at arm.com Wed Jun 27 07:41:41 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Wed, 27 Jun 2018 07:41:41 +0000 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi, Andrew, Look good to me. Just nits: the "import java.lang.reflect.Field; import jdk.internal.misc.Unsafe;" in TestVolatileLoad.java and TestVolatileStore.java are unnecessary. -- Best regards, Zhongwei ________________________________________ From: aarch64-port-dev on behalf of Andrew Dinn Sent: Wednesday, June 27, 2018 12:55 AM To: aarch64-port-dev at openjdk.java.net; hotspot compiler Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation Reviews are welcome for the following webrev webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 The patch: ---------- This AArch64-only patch adds tests to ensure that volatile load, store and CAS operations are either: translated to correctly replace memory barriers with combinations of acquiring loads and releasing left untransformed with all necessary memory barriers in place The test requires a debug, aarch64 vm and is disabled if graal is being used (debug is necessary because it relies on -XX:+PrintOptoAssembly to provide evidence of what is in the compiler output). The main driver test program creates subordinate JVMs to execute subordinate programs which perform: normal and unsafe volatile loads, normal and unsafe volatile stores unsafe volatile CASes in each of 5 GC configurations: G1 CMS+CondCardMark CMS-CondCardMark Parallel Serial Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are used to generate Assembly listings and the driver test program parses these to ensure the correct sequences of instructions are generated (including omitted memory barriers which are flagged in the output). A few changes were made to the aarch64.ad file to ensure that the PrintOptoAssembly output accurately represented the generated code. These were necessary to ensure that the test could be sure that the generated code sequences really were what was intended. Also, some of the comments in aarch64.ad describing the code transformation were updated following feedback from Zhongwei Yao that arrived too late to get checked in with the fix for JDK-8204331. Testing: -------- The test itself passes when run on an AArch64 debug vm. It is ignored when run on an AArch64 product vm. No other testing is needed. Nothing significant in the aarch64.ad file has been modified (only comments of format sequences which have been exercised running the new test). 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From adinn at redhat.com Wed Jun 27 07:56:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 08:56:37 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <5c631885-8516-1aad-b978-596aa32209c6@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <5c631885-8516-1aad-b978-596aa32209c6@redhat.com> Message-ID: <87229b6f-4de4-037b-356a-bf28aaa6bde7@redhat.com> On 26/06/18 18:10, Andrew Haley wrote: > On 06/26/2018 05:55 PM, Andrew Dinn wrote: >> webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/ >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > Yowza. > > OK, so that wasn't a proper review. This looks great, and pretty > thorough. I'm sure there are still some ways in which the logic might > fail and not be caught, but this should get the obvious ones. > > I don't much like the assert() rathern than guarantee() for the > failures in C2. Won't we just crash anyway if these asserts fail? If > so, we might as well use guarantee(). We may not always crash if these asserts fail. However, we probably want to because we don't know that the translation to use ldar and stlr insns is being applied consistently. Better to crash and fix than be left trying to track down mysterious memory bugs. I'll fix this in an updated webrev. 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 adinn at redhat.com Wed Jun 27 07:57:42 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 08:57:42 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <5da7153e-631c-ca41-4cd8-00a0656b6d6e@redhat.com> Hi Vladimir, On 26/06/18 18:23, Vladimir Kozlov wrote: > Small note - all files should have Copyright header. I see only main > test file have one. Thanks for looking at this. I'll fix that in the next version. 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 adinn at redhat.com Wed Jun 27 10:54:59 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 11:54:59 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: Hi Dmitrij, On 26/06/18 19:33, Dmitrij Pochepko wrote: > Overall looks good, but I have few minor comments regarding these tests: Thanks for reviewing the patch. > 1. Most tests which spawn other precesses for testing purposes are > launched as "@run driver ..." for optimization reasons. I'm using the Process API so I can retrieve and analyze the output written to the spawned JVM's stdout. Is it possible to do that using "@run driver"? > 2. Do we really need to ignore external vm options set in jtreg via > option: -javaoptions:""? In case these tests > shouldn't ignore external options, there is > ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, > String... command) for that. Hmm, good question. I cannot see a need to pass on any extra test options to the spawned JVMs at the moment. The only reason to create the spawned process is to observe how the JIT generates code for volatile ops and, as far as I am aware, all relevant JIT and GC options that affect that aspect of its operation are specified in the test. However, I may well have overlooked something. Do you have a specific reason for thinking that certain JVM options need to be passed on? If not perhaps we could consider passing on extra javaoptions if/when a case for it arises. > 3. This test will fail if jdk will be built without all GCs or without > C2. It probably a good idea to split it in few tests with separate GC > configurations Well, I had thought about splitting out separate tests for some GCs, although I was only motivated to do so for Shenandoah and ZGC -- to cope with their potential presence/absence. The test may also eventually need to allow for future disappearance of CMS (currently deprecated). However, that event will also require changes to the JIT code to make the case handling for CMS conditional on its presence/absence -- I am inclined to postpone any such surgery on the current test until CMS goes away. However, I don't understand how splitting the tests up is going to help deal with the either of the two config omissions you are concerned about. Consider first the question of whether C2 is present. I could specify @requires vm.flavor=="server" in the header comment but I believe that would only indicate that "--server" has been passed as an argument to the jtreg test jvm. That flag could be absent and the JVM could still include a C2 compiler. However, by adding it as a requirement the result would be that the test would only get run if the test run explicitly passes "-server" i.e. it would effectively disable the test. Similarly, if I put, say, the parallel tests into a separate file I could then add @requires vm.gc = "Parallel". However, once again I believe that would only detect whether the jtreg test jvm had been started using -XX:+UseParallelGC. It would not ensure that the test would be run using a Parallel GC when some other GC was configured for jtreg. Nor would it identify whether that a Parallel GC was available into the JVM being tested. SO, once again it would disable all tests (except, perhaps, those for G1). If I have misunderstood how the @requires config works and how splitting the tests up would improve clarity of test outcomes then I'd be happy to be corrected here. Also, I am not really sure how important it is to make this test work when the config omits C2 or removes all GCs. This test is needed to make sure that the standard AArch64 build which includes C2 and all GCs is not broken. That's the critical case to validate. I'd prefer to leave this as is for now unless and until jtreg makes it possible to identify whether a specific JIT or GC is available in a JVM under test as opposed to testing what GC is configured on the jtreg command line. > 4. In case external options are not ignored, you'll need to filter out > several vm options, like skipping execution for c1 or interpreter > testruns. Something like this can be added: @requires vm.compMode != > "Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | > vm.opt.TieredStopAtLevel==4) I don't think that is needed given that I don't intend to pass on the jtreg test options. 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 dmitrij.pochepko at bell-sw.com Wed Jun 27 12:29:41 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 15:29:41 +0300 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> On 27.06.2018 13:54, Andrew Dinn wrote: > Hi Dmitrij, > > On 26/06/18 19:33, Dmitrij Pochepko wrote: >> Overall looks good, but I have few minor comments regarding these tests: > Thanks for reviewing the patch. I'm not an official reviewed though >> 1. Most tests which spawn other precesses for testing purposes are >> launched as "@run driver ..." for optimization reasons. > I'm using the Process API so I can retrieve and analyze the output > written to the spawned JVM's stdout. Is it possible to do that using > "@run driver"? yes >> 2. Do we really need to ignore external vm options set in jtreg via >> option: -javaoptions:""? In case these tests >> shouldn't ignore external options, there is >> ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, >> String... command) for that. > Hmm, good question. I cannot see a need to pass on any extra test > options to the spawned JVMs at the moment. The only reason to create the > spawned process is to observe how the JIT generates code for volatile > ops and, as far as I am aware, all relevant JIT and GC options that > affect that aspect of its operation are specified in the test. However, > I may well have overlooked something. > > Do you have a specific reason for thinking that certain JVM options need > to be passed on? If not perhaps we could consider passing on extra > javaoptions if/when a case for it arises. Well, not particular reason for that. There are few examples thought, like launching testing with some agent, or specific heap size e.t.c. > >> 3. This test will fail if jdk will be built without all GCs or without >> C2. It probably a good idea to split it in few tests with separate GC >> configurations > Well, I had thought about splitting out separate tests for some GCs, > although I was only motivated to do so for Shenandoah and ZGC -- to cope > with their potential presence/absence. > > The test may also eventually need to allow for future disappearance of > CMS (currently deprecated). However, that event will also require > changes to the JIT code to make the case handling for CMS conditional on > its presence/absence -- I am inclined to postpone any such surgery on > the current test until CMS goes away. > > However, I don't understand how splitting the tests up is going to help > deal with the either of the two config omissions you are concerned > about. It is a test granularity question. Splitting tests will reduce time for failure diagnostic. When looking at test report it makes a difference at first glance to see: TestVolatiles.java failed or TestVolatilesG1.java failed, or all TestVolatiles*.java failed. If you think this granularity is fine, then let it be. > Consider first the question of whether C2 is present. I could > specify @requires vm.flavor=="server" in the header comment but I > believe that would only indicate that "--server" has been passed as an > argument to the jtreg test jvm. That flag could be absent and the JVM > could still include a C2 compiler. However, by adding it as a > requirement the result would be that the test would only get run if the > test run explicitly passes "-server" i.e. it would effectively disable > the test. > > Similarly, if I put, say, the parallel tests into a separate file I > could then add @requires vm.gc = "Parallel". However, once again I > believe that would only detect whether the jtreg test jvm had been > started using -XX:+UseParallelGC. It would not ensure that the test > would be run using a Parallel GC when some other GC was configured for > jtreg. Nor would it identify whether that a Parallel GC was available > into the JVM being tested. SO, once again it would disable all tests > (except, perhaps, those for G1). > > If I have misunderstood how the @requires config works and how splitting > the tests up would improve clarity of test outcomes then I'd be happy to > be corrected here. It's not like that. vm.flavor doesn't check flags. It parse vm property "java.vm.name". vm.gc.* are also not that simple. You can check how additional "requires" properties are constructed in test/jtreg-ext/requires/VMProps.java However, since you probably won't pass external options, you won't need it. Just FYI. > > Also, I am not really sure how important it is to make this test work > when the config omits C2 or removes all GCs. This test is needed to make > sure that the standard AArch64 build which includes C2 and all GCs is > not broken. That's the critical case to validate. I'd prefer to leave > this as is for now unless and until jtreg makes it possible to identify > whether a specific JIT or GC is available in a JVM under test as opposed > to testing what GC is configured on the jtreg command line. ok > >> 4. In case external options are not ignored, you'll need to filter out >> several vm options, like skipping execution for c1 or interpreter >> testruns. Something like this can be added: @requires vm.compMode != >> "Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | >> vm.opt.TieredStopAtLevel==4) > I don't think that is needed given that I don't intend to pass on the > jtreg test options. ok > > 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 adinn at redhat.com Wed Jun 27 13:05:25 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 14:05:25 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> Message-ID: On 27/06/18 13:29, Dmitrij Pochepko wrote: > On 27.06.2018 13:54, Andrew Dinn wrote: >> Hi Dmitrij, >> >> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>> Overall looks good, but I have few minor comments regarding these tests: >> Thanks for reviewing the patch.> I'm not an official reviewed though That's ok. You don't need to be an official reviewer to offer review comments :-) >>> 1. Most tests which spawn other precesses for testing purposes are >>> launched as "@run driver ..." for optimization reasons. >> I'm using the Process API so I can retrieve and analyze the output >> written to the spawned JVM's stdout. Is it possible to do that using >> "@run driver"? > yes Well, that's good to know ;-) but still could you explain how or point at an example? >> However, I don't understand how splitting the tests up is going to help >> deal with the either of the two config omissions you are concerned >> about. > It is a test granularity question. Splitting tests will reduce time for > failure diagnostic. When looking at test report it makes a difference at > first glance to see: TestVolatiles.java failed or TestVolatilesG1.java > failed, or all TestVolatiles*.java failed. If you think this granularity > is fine, then let it be. Ok, I take your point about granularity of failure. I'll address this in the next webrev. >> If I have misunderstood how the @requires config works and how splitting >> the tests up would improve clarity of test outcomes then I'd be happy to >> be corrected here. > It's not like that. vm.flavor doesn't check flags. It parse vm property > "java.vm.name". > vm.gc.* are also not that simple. You can check how additional > "requires" properties are constructed in > test/jtreg-ext/requires/VMProps.java Ah, ok, thanks for pointing me at that. All I had been able to decipher up to now was what the jtreg code was doing. I didn't know that there was an extension package in the JVM test tree that allowed JVM capabilities to be identified. I'll use that to extend the requires predicate for the tests. 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 adinn at redhat.com Wed Jun 27 13:06:23 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 14:06:23 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: On 27/06/18 08:41, Zhongwei Yao wrote: > Look good to me. > > Just nits: the "import java.lang.reflect.Field; import jdk.internal.misc.Unsafe;" in TestVolatileLoad.java and TestVolatileStore.java are unnecessary. Thanks, Zhongwei -- I'll remove them in the next webrev :-) 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 dmitrij.pochepko at bell-sw.com Wed Jun 27 14:41:34 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 17:41:34 +0300 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> Message-ID: <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> On 27.06.2018 16:05, Andrew Dinn wrote: > On 27/06/18 13:29, Dmitrij Pochepko wrote: >> On 27.06.2018 13:54, Andrew Dinn wrote: >>> Hi Dmitrij, >>> >>> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>>> Overall looks good, but I have few minor comments regarding these tests: >>> Thanks for reviewing the patch.> I'm not an official reviewed though > That's ok. You don't need to be an official reviewer to offer review > comments :-) > >>>> 1. Most tests which spawn other precesses for testing purposes are >>>> launched as "@run driver ..." for optimization reasons. >>> I'm using the Process API so I can retrieve and analyze the output >>> written to the spawned JVM's stdout. Is it possible to do that using >>> "@run driver"? >> yes > Well, that's good to know ;-) but still could you explain how or point > at an example? it's the same as for @run main. External vm options are stored by jtreg in several vm properties: test.vm.opts and test.java.opts (for -vmoptions and -javaoptions respectively), so, process tools use it in case you call createJavaProcessBuilder with first parameter == true. Here is an example how this could be done: gc/arguments/TestUseNUMAInterleaving.java > >>> However, I don't understand how splitting the tests up is going to help >>> deal with the either of the two config omissions you are concerned >>> about. >> It is a test granularity question. Splitting tests will reduce time for >> failure diagnostic. When looking at test report it makes a difference at >> first glance to see: TestVolatiles.java failed or TestVolatilesG1.java >> failed, or all TestVolatiles*.java failed. If you think this granularity >> is fine, then let it be. > Ok, I take your point about granularity of failure. I'll address this in > the next webrev. > >>> If I have misunderstood how the @requires config works and how splitting >>> the tests up would improve clarity of test outcomes then I'd be happy to >>> be corrected here. >> It's not like that. vm.flavor doesn't check flags. It parse vm property >> "java.vm.name". >> vm.gc.* are also not that simple. You can check how additional >> "requires" properties are constructed in >> test/jtreg-ext/requires/VMProps.java > Ah, ok, thanks for pointing me at that. All I had been able to decipher > up to now was what the jtreg code was doing. I didn't know that there > was an extension package in the JVM test tree that allowed JVM > capabilities to be identified. I'll use that to extend the requires > predicate for the tests. > > 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 adinn at redhat.com Wed Jun 27 15:03:13 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 16:03:13 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> Message-ID: <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> On 27/06/18 15:41, Dmitrij Pochepko wrote: > On 27.06.2018 16:05, Andrew Dinn wrote: >> On 27/06/18 13:29, Dmitrij Pochepko wrote: >>> On 27.06.2018 13:54, Andrew Dinn wrote: >>>> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>>>> 1. Most tests which spawn other precesses for testing purposes are >>>>> launched as "@run driver ..." for optimization reasons. >>>> I'm using the Process API so I can retrieve and analyze the output >>>> written to the spawned JVM's stdout. Is it possible to do that using >>>> "@run driver"? >>> yes >> Well, that's good to know ;-) but still could you explain how or point >> at an example? > it's the same as for @run main. External vm options are stored by jtreg > in several vm properties: test.vm.opts and test.java.opts (for > -vmoptions and -javaoptions respectively), so, process tools use it in > case you call createJavaProcessBuilder with first parameter == true. > Here is an example how this could be done: > gc/arguments/TestUseNUMAInterleaving.java I'm really not sure what you are recommending here. Are you simply saying that I need to change the @run directives so that they say @run driver compiler.c2.aarch64.TestVolatiles instead of @run main compiler.c2.aarch64.TestVolatiles If so then I can easily do that but I would really like to understand why that is better -- as you say -- 'for optimization reasons'. Could you clarify if that is all you are suggesting and if so why it improves the situation? If, instead, you are suggesting I do something more (or something else) then can you give a precise and clear explanation of what I would need to change and why? For now it would be best to base that on the original webrev just to avoid any further confusion. 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 dmitrij.pochepko at bell-sw.com Wed Jun 27 16:10:38 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 20:10:38 +0400 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> Message-ID: <5B33B6FE.7080502@bell-sw.com> 27.06.2018 19:03, Andrew Dinn ?????: > On 27/06/18 15:41, Dmitrij Pochepko wrote: >> On 27.06.2018 16:05, Andrew Dinn wrote: >>> On 27/06/18 13:29, Dmitrij Pochepko wrote: >>>> On 27.06.2018 13:54, Andrew Dinn wrote: >>>>> On 26/06/18 19:33, Dmitrij Pochepko wrote: >>>>>> 1. Most tests which spawn other precesses for testing purposes are >>>>>> launched as "@run driver ..." for optimization reasons. >>>>> I'm using the Process API so I can retrieve and analyze the output >>>>> written to the spawned JVM's stdout. Is it possible to do that using >>>>> "@run driver"? >>>> yes >>> Well, that's good to know ;-) but still could you explain how or point >>> at an example? >> it's the same as for @run main. External vm options are stored by jtreg >> in several vm properties: test.vm.opts and test.java.opts (for >> -vmoptions and -javaoptions respectively), so, process tools use it in >> case you call createJavaProcessBuilder with first parameter == true. >> Here is an example how this could be done: >> gc/arguments/TestUseNUMAInterleaving.java > > I'm really not sure what you are recommending here. Are you simply > saying that I need to change the @run directives so that they say > > @run driver compiler.c2.aarch64.TestVolatiles > > instead of > > @run main compiler.c2.aarch64.TestVolatiles > > If so then I can easily do that but I would really like to understand > why that is better -- as you say -- 'for optimization reasons'. > > Could you clarify if that is all you are suggesting and if so why it > improves the situation? Yes. It is exactly what I'm suggesting. @run driver is a specifical subform of @run main, which always run in same vm as jtreg, without spawning additional java process. Official jtreg guideline also says about driver(http://openjdk.java.net/jtreg/tag-spec.html): "Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM." > > If, instead, you are suggesting I do something more (or something else) > then can you give a precise and clear explanation of what I would need > to change and why? For now it would be best to base that on the original > webrev just to avoid any further confusion. > > 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 adinn at redhat.com Wed Jun 27 16:28:55 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 17:28:55 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> Message-ID: <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> Here is an updated webrev which addresses all comments modulo Dmitrij's recommendation about use of @run driver for which I am still awaiting clarification. I hope the changes described below are satisfactory. webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.01 JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 Dmitirj, if you can explain what else I need to tweak then I'll be happy to update the webrev. If not please let me know if it is ok to push. Changes: Modified asserts in the aarch64.ad predicates to guarantees in all cases where they relate to expectations about the graph structure. The ones that are still left as asserts refer to expectations about what nodes should be passed as predicate arguments i.e. the former are about consistency external to the aarch64.ad file and the latter to internal consistency (I don't believe the latter merit a check in product code). Added copyright headers to all test files Turned the original test class (TestVolatiles) into a test runner which can be used to check a specific volatile op + GC config combination. Added 5 new test classes (TestVolatilesG1, TestVolatilesSerial, TestVolatilesParallel, TestVolatilesCMS, and TestVolatilesCMSCardMark) which indirect control to TestVolatiles to test each of the 5 different volatile ops with one of the relevant GC configurations. Added @require conditions to each of the 5 new tests to ensure it is run in a server GC and that the GC confguration under test is supported by the JVM. Testing: All 5 tests passed on a debug, server VM. 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 adinn at redhat.com Wed Jun 27 16:32:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 27 Jun 2018 17:32:37 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <5B33B6FE.7080502@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <20902a61-5224-ac05-88d0-445c01b78902@bell-sw.com> <3c2d1773-1ba1-94ad-52b8-dc6a08dfc5e3@bell-sw.com> <46ba0968-1270-1c72-3cd4-e7c1fd6a3a92@redhat.com> <5B33B6FE.7080502@bell-sw.com> Message-ID: On 27/06/18 17:10, Dmitrij Pochepko wrote: > 27.06.2018 19:03, Andrew Dinn ?????: >> I'm really not sure what you are recommending here. Are you simply >> saying that I need to change the @run directives so that they say >> >> ?? @run driver compiler.c2.aarch64.TestVolatiles >> >> instead of >> >> ?? @run main compiler.c2.aarch64.TestVolatiles >> >> If so then I can easily do that but I would really like to understand >> why that is better -- as you say -- 'for optimization reasons'. >> >> Could you clarify if that is all you are suggesting and if so why it >> improves the situation? > Yes. It is exactly what I'm suggesting. @run driver is a specifical > subform of @run main, which always run in same vm as jtreg, without > spawning additional java process. Ok, thanks for explaining. I'll tweak the latest webrev (just posted details) so that @run main is replaced with @run driver. 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 dmitrij.pochepko at bell-sw.com Wed Jun 27 16:40:50 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 27 Jun 2018 20:40:50 +0400 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> Message-ID: <5B33BE12.805@bell-sw.com> Hi, looks good to me(with @run main changed to @run driver) Thanks, Dmitrij 27.06.2018 20:28, Andrew Dinn wrote: > Here is an updated webrev which addresses all comments modulo Dmitrij's > recommendation about use of @run driver for which I am still awaiting > clarification. I hope the changes described below are satisfactory. > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.01 > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > Dmitirj, if you can explain what else I need to tweak then I'll be happy > to update the webrev. If not please let me know if it is ok to push. > > Changes: > > Modified asserts in the aarch64.ad predicates to guarantees in all cases > where they relate to expectations about the graph structure. The ones > that are still left as asserts refer to expectations about what nodes > should be passed as predicate arguments i.e. the former are about > consistency external to the aarch64.ad file and the latter to internal > consistency (I don't believe the latter merit a check in product code). > > Added copyright headers to all test files > > Turned the original test class (TestVolatiles) into a test runner which > can be used to check a specific volatile op + GC config combination. > > Added 5 new test classes (TestVolatilesG1, TestVolatilesSerial, > TestVolatilesParallel, TestVolatilesCMS, and TestVolatilesCMSCardMark) > which indirect control to TestVolatiles to test each of the 5 different > volatile ops with one of the relevant GC configurations. > > Added @require conditions to each of the 5 new tests to ensure it is run > in a server GC and that the GC confguration under test is supported by > the JVM. > > Testing: > > All 5 tests passed on a debug, server VM. > > 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 Zhongwei.Yao at arm.com Thu Jun 28 09:21:10 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Thu, 28 Jun 2018 09:21:10 +0000 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: <5B33BE12.805@bell-sw.com> References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com>,<5B33BE12.805@bell-sw.com> Message-ID: Hi, Andrew, Sorry for my separate comment, but I have a question about "storestore" barrier eliding in StoreCM node. In http://cr.openjdk.java.net/~adinn/8205694/webrev.01/test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java.html line: 301, when "storestore" barrier is elided, is following sequence still ordered?: stlrw strb To my knowledge, strb could be reordered in above sequence. But "stlrw; stlrb" will be ordered as following said. And I see some discrepancy in the comment of aarch64.ad (without your patch applied, line: 1483 to 1484), storeCM is translated to: dmb ishst strlb But actually, it is translated to: dmb ishst strb So either the comment should be updated, or the code generated is not correct. -- Best regards, Zhongwei ________________________________________ From: aarch64-port-dev on behalf of Dmitrij Pochepko Sent: Thursday, June 28, 2018 12:40:50 AM To: Andrew Dinn Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation Hi, looks good to me(with @run main changed to @run driver) Thanks, Dmitrij 27.06.2018 20:28, Andrew Dinn wrote: > Here is an updated webrev which addresses all comments modulo Dmitrij's > recommendation about use of @run driver for which I am still awaiting > clarification. I hope the changes described below are satisfactory. > > webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.01 > JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694 > > Dmitirj, if you can explain what else I need to tweak then I'll be happy > to update the webrev. If not please let me know if it is ok to push. > > Changes: > > Modified asserts in the aarch64.ad predicates to guarantees in all cases > where they relate to expectations about the graph structure. The ones > that are still left as asserts refer to expectations about what nodes > should be passed as predicate arguments i.e. the former are about > consistency external to the aarch64.ad file and the latter to internal > consistency (I don't believe the latter merit a check in product code). > > Added copyright headers to all test files > > Turned the original test class (TestVolatiles) into a test runner which > can be used to check a specific volatile op + GC config combination. > > Added 5 new test classes (TestVolatilesG1, TestVolatilesSerial, > TestVolatilesParallel, TestVolatilesCMS, and TestVolatilesCMSCardMark) > which indirect control to TestVolatiles to test each of the 5 different > volatile ops with one of the relevant GC configurations. > > Added @require conditions to each of the 5 new tests to ensure it is run > in a server GC and that the GC confguration under test is supported by > the JVM. > > Testing: > > All 5 tests passed on a debug, server VM. > > 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 adinn at redhat.com Thu Jun 28 10:54:26 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Jun 2018 11:54:26 +0100 Subject: [aarch64-port-dev ] RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation In-Reply-To: References: <728514b0-47d0-62fc-5a49-289f7ff75d19@redhat.com> <30a5c2f9-704d-8b9e-d947-16e6f5ec34cc@redhat.com> <5B33BE12.805@bell-sw.com> Message-ID: <2378c5e0-aac0-c2b0-ce2c-0da2788dd27d@redhat.com> Hi Zhongwei, Thanks very much for looking at this. On 28/06/18 10:21, Zhongwei Yao wrote: > Sorry for my separate comment, but I have a question about > "storestore" barrier eliding in StoreCM node. > > In http://cr.openjdk.java.net/~adinn/8205694/webrev.01/test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java.html > line: 301, when "storestore" barrier is elided, is following sequence > still ordered?: > stlrw > strb > > To my knowledge, strb could be reordered in above sequence. But "stlrw; > stlrb" will be ordered as following said. This was discussed some time ago when the original change was made and I believe it is correct. G1 and CMS both insert a StoreCM node into the node graph to model at an abstract level the card mark that should follow a StoreP/N (volatile or non-volatile). The other two standard GCs (Parallel, Serial) simply insert a StoreB. The purpose of the StoreCM is to allow non-TSO architectures to generate a StoreStore barrier between the str generated for the StoreP/N and the strb generated for the StoreCM i.e. ensure they are correctly ordered. For Aarch64, that would mean planting something like 1) normal 2) volatile 3) volatile via stlr via barriers dmb ish str stlr str . . . . . . . . . dmb ishst dmb ishst dmb ishst . . . . . . . . . strb strb strb dmb ish where the ... might be replaced with other instructions generated in accordance with the GC barrier. First, notice that in case 2 the StoreStore barrier is always redundant because the StoreP/N has been translated to stlr. This guarantees that the field write is visible before the card mark. So, we can always omit the dmb ishst if we know we are translating a volatile store. However, the predicate for unnecessary_storestore also optimizes two further cases. For G1, the GC barrier plants a card mark membar_volatile between the StoreP/N and the StoreCM. So, for this case if we generated a storestore barrier we would see this 1) normal 2) volatile 3) volatile via stlr via barriers dmb ish str stlr str . . . . . . . . . dmb ish dmb ish dmb ish . . . . . . . . . dmb ishst dmb ishst dmb ishst . . . . . . . . . strb strb strb dmb ish Clearly, the dmb ishst is not needed for G1. The same thing applies when using CMS with +UseCondCardMark. The GC barrier for this case introduces a card mark membar_volatile between the str/stlr and strb as with G1. So, this makes the dmb ishst redundant in all 3 cases. CMS with -UseCondCardMark does not introduce a card mark membar_volatile. So, in that case that we need to introduce the dmb ishst in cases 1 and 3. If we have case 2 i.e. we know we have a volatile store and are not relying on barriers it can be omitted. I believe the checks in the predicate test for precisely these conditions. > And I see some discrepancy in the comment of aarch64.ad (without > your patch applied, line: 1483 to 1484), storeCM is translated to: > dmb ishst > strlb > > But actually, it is translated to: > dmb ishst > strb Yes, that comment is wrong. It should say strb. I am afraid I have already pushed the fix. Perhaps we can sneak a patch to the comment into a later fix. 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