From aph at redhat.com Fri Nov 1 10:15:37 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Nov 2019 10:15:37 +0000 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> Message-ID: <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> On 10/31/19 6:48 PM, Zhengyu Gu wrote: > Right now, the decisions on, if a load barrier needs load reference > barrier, if so, what kind? and if the reference needs to be kept alive, > are scattered inside interpreter/c1/2 load barrier code, which is hard > to make them consistent. > > I would like to centralize the decision making into > ShenandoahBarrierSet, so them can be consistent and easy to maintain. You should say, at the start of every routine you touch, which registers are inputs, which are outputs, and (important) which may alias with rscratch1 and rscratch2. Please also mark clobbers of rscratch1 and 2. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Fri Nov 1 14:06:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Nov 2019 15:06:50 +0100 Subject: RFR (S) 8233387: Shenandoah: passive mode should disable pacing ergonomically Message-ID: <43d07d59-f685-23a9-7a73-38e7284a341f@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8233387 This is the follow-up from JDK-8232791. There, we have added the ergonomic disable block in ShenandoahPassiveHeuristics. But, there is already the disable block in ShenandoahPassiveMode! In fact, it was there in ShenandoaPassiveHeuristics before introducing ShenandoahPassiveMode. We should revert JDK-8232791, and set the flag ergonomically in ShenandoahPassiveMode. Fix: https://cr.openjdk.java.net/~shade/8233387/webrev.01/ Testing: eyeballing GC logs, hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Fri Nov 1 14:15:56 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 1 Nov 2019 10:15:56 -0400 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> Message-ID: >> >> I would like to centralize the decision making into >> ShenandoahBarrierSet, so them can be consistent and easy to maintain. > > You should say, at the start of every routine you touch, which > registers are inputs, which are outputs, and (important) which may > alias with rscratch1 and rscratch2. Please also mark clobbers of > rscratch1 and 2. > Okay, updated: Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.01/index.html Thanks, -Zhengyu From zgu at redhat.com Fri Nov 1 14:55:03 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 1 Nov 2019 10:55:03 -0400 Subject: RFR (S) 8233387: Shenandoah: passive mode should disable pacing ergonomically In-Reply-To: <43d07d59-f685-23a9-7a73-38e7284a341f@redhat.com> References: <43d07d59-f685-23a9-7a73-38e7284a341f@redhat.com> Message-ID: <9e721547-6d76-3ab7-3048-0f335b32186b@redhat.com> Good to me. -Zhengyu On 11/1/19 10:06 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8233387 > > This is the follow-up from JDK-8232791. There, we have added the ergonomic disable block in > ShenandoahPassiveHeuristics. But, there is already the disable block in ShenandoahPassiveMode! In > fact, it was there in ShenandoaPassiveHeuristics before introducing ShenandoahPassiveMode. We should > revert JDK-8232791, and set the flag ergonomically in ShenandoahPassiveMode. > > Fix: > https://cr.openjdk.java.net/~shade/8233387/webrev.01/ > > Testing: eyeballing GC logs, hotspot_gc_shenandoah > From shade at redhat.com Fri Nov 1 15:31:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Nov 2019 16:31:33 +0100 Subject: heap memory usage increasing over time with a fixed live set size In-Reply-To: References: Message-ID: <1d366247-c26c-19f7-6234-76b88cbe2077@redhat.com> On 10/9/19 2:52 PM, Amir Hadadi wrote: > I see that when a degenerated gc occasionally happens due to allocation failure, class unloading gets the memory back to baseline level. > The logs also show that there's a serious amount of strings being removed from the string table, probably due to Jackson interning field names. I knew that sounded familiar: https://github.com/FasterXML/jackson-core/issues/378 https://github.com/FasterXML/jackson-core/issues/332 If I read those threads right, if you upgrade to Jackson 3.0+, field names interning would go away. Ditto should happen if you override JsonFactory.Feature.INTERN_FIELD_NAMES to false. -- Thanks, -Aleksey From shade at redhat.com Fri Nov 1 15:43:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Nov 2019 16:43:20 +0100 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> Message-ID: <0fb9cd70-0a89-8c14-7469-55205c4c3808@redhat.com> On 11/1/19 3:15 PM, Zhengyu Gu wrote: > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.01/index.html To be honest, it does not look like much of the improvement from the first glance. Maybe we should massage the code a bit to make it more readable? Roman also needs to take a look. *) shenandoahBarrierSetAssembler_x86.cpp, I believe it would be more straightforward to save branching on local variable "need_load_reference_barrier" by spelling out the "disabled" path directly (in fact, I think you are almost there in shenandoahBarrierSetC1.cpp!): if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { BarrierSetAssembler::load_at(masm, decorators, type, dst, src, tmp1, tmp_thread); return; } ... code that assumes need_load_reference_barrier = true follows ... Register result_dst = dst; bool use_tmp1_for_dst = false; *) shenandoahBarrierSetC1.cpp: local variable "need_load_reference_barrier" is not needed, there is only a single use *) shenandoahBarrierSetC2.cpp: this block should go all the way up: 557 if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { 558 return load; 559 } *) shenandoahBarrierSet.cpp: this is just "return is_reference_type(type)". Saves some inversions. 78 if (!is_reference_type(type)) return false; 79 return true; *) shenandoahBarrierSet.cpp: should be "Should be subset of LRB": 83 assert(need_load_reference_barrier(decorators, type), "Why ask?"); *) shenandoahBarrierSet.cpp: seems like this assert is subsumed by the previous one? 84 assert(is_reference_type(type), "Why we here?"); -- Thanks, -Aleksey From shade at redhat.com Fri Nov 1 15:51:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Nov 2019 16:51:17 +0100 Subject: [11] RFR: 2019-11-01, Follow-up backports to sh/jdk11 Message-ID: Hi, I would like to push two follow-up backports to sh/jdk11: [backport] 8233303: Shenandoah: verifier assert erroneously uses byte_size_in_exact_unit [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically Webrev: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20191101/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From zgu at redhat.com Fri Nov 1 17:37:49 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 1 Nov 2019 13:37:49 -0400 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: <0fb9cd70-0a89-8c14-7469-55205c4c3808@redhat.com> References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> <0fb9cd70-0a89-8c14-7469-55205c4c3808@redhat.com> Message-ID: Hi Aleksey, On 11/1/19 11:43 AM, Aleksey Shipilev wrote: > On 11/1/19 3:15 PM, Zhengyu Gu wrote: >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.01/index.html > > To be honest, it does not look like much of the improvement from the first glance. Maybe we should > massage the code a bit to make it more readable? Roman also needs to take a look. Right, it is not. But I believe that should be done in separate CR, as it may cause backport headache, right? Filed: https://bugs.openjdk.java.net/browse/JDK-8233401 Matter of fact, I would like to hold off this code review, till reactor is done. Thanks, -Zhengyu > > *) shenandoahBarrierSetAssembler_x86.cpp, I believe it would be more straightforward to save > branching on local variable "need_load_reference_barrier" by spelling out the "disabled" path > directly (in fact, I think you are almost there in shenandoahBarrierSetC1.cpp!): > > if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { > BarrierSetAssembler::load_at(masm, decorators, type, dst, src, tmp1, tmp_thread); > return; > } > > ... code that assumes need_load_reference_barrier = true follows ... > > Register result_dst = dst; > bool use_tmp1_for_dst = false; > > *) shenandoahBarrierSetC1.cpp: local variable "need_load_reference_barrier" is not needed, there is > only a single use > > *) shenandoahBarrierSetC2.cpp: this block should go all the way up: > > 557 if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { > 558 return load; > 559 } > > *) shenandoahBarrierSet.cpp: this is just "return is_reference_type(type)". Saves some inversions. > > 78 if (!is_reference_type(type)) return false; > 79 return true; > > *) shenandoahBarrierSet.cpp: should be "Should be subset of LRB": > > 83 assert(need_load_reference_barrier(decorators, type), "Why ask?"); > > *) shenandoahBarrierSet.cpp: seems like this assert is subsumed by the previous one? > > 84 assert(is_reference_type(type), "Why we here?"); > > From alex at bytopia.org Fri Nov 1 20:21:59 2019 From: alex at bytopia.org (Alexander Yakushev) Date: Fri, 1 Nov 2019 22:21:59 +0200 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 Message-ID: This happened two times today as I increased the load on the process. Here's a piece of the error file: https://gist.github.com/alexander-yakushev/828617521ab0368d7bff854745f1fec8. I can't share all of it, unfortunately, but I will try to make a lightweight reproducible case Hope this helps, I will try to provide more context if necessary. From shade at redhat.com Fri Nov 1 21:50:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Nov 2019 22:50:30 +0100 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: Message-ID: On 11/1/19 9:21 PM, Alexander Yakushev wrote: > This happened two times today as I increased the load on the process. > Here's a piece of the error file: > https://gist.github.com/alexander-yakushev/828617521ab0368d7bff854745f1fec8. > I can't share all of it, unfortunately, but I will try to make a > lightweight reproducible case Yes, MCVE would be very handy. > Hope this helps, I will try to provide more context if necessary. Full hs_err; fastdebug build; +ShenandoahVerify -- or any combination of the above would help. Also, hs_err seems to indicate you are running b450 from Oct 30; we have already fixed some follow-up bugs, you might want to pull the fresh build and try again. -- Thanks, -Aleksey From zgu at redhat.com Sat Nov 2 15:07:31 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Sat, 2 Nov 2019 11:07:31 -0400 Subject: RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code Message-ID: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Please review this refactor of Shenandoah load barrier. The goal is to make the barrier structurally similar cross interpreter, C1 and C2, improve readability and maintainability. Bug: https://bugs.openjdk.java.net/browse/JDK-8233401 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) x86_64 and x86_32 on Linux AArch64 on Linux Thanks, -Zhengyu From amirhadadi at hotmail.com Sun Nov 3 07:43:25 2019 From: amirhadadi at hotmail.com (Amir Hadadi) Date: Sun, 3 Nov 2019 07:43:25 +0000 Subject: heap memory usage increasing over time with a fixed live set size In-Reply-To: <1d366247-c26c-19f7-6234-76b88cbe2077@redhat.com> References: , <1d366247-c26c-19f7-6234-76b88cbe2077@redhat.com> Message-ID: Thanks Alexey! Once concurrent class unloading is incorporated, when will it be triggered? Evidently running it only on special occasions (e.g. degenerated gc) can become a nasty performance race to the bottom for certain workloads. Will it be triggered as if -XX:+ClassUnloadingWithConcurrentMark was enabled, making this flag a no op? What are the plans in that respect? ________________________________ From: Aleksey Shipilev Sent: Friday, November 1, 2019 5:31 PM To: Amir Hadadi ; shenandoah-dev at openjdk.java.net Subject: Re: heap memory usage increasing over time with a fixed live set size On 10/9/19 2:52 PM, Amir Hadadi wrote: > I see that when a degenerated gc occasionally happens due to allocation failure, class unloading gets the memory back to baseline level. > The logs also show that there's a serious amount of strings being removed from the string table, probably due to Jackson interning field names. I knew that sounded familiar: https://github.com/FasterXML/jackson-core/issues/378 https://github.com/FasterXML/jackson-core/issues/332 If I read those threads right, if you upgrade to Jackson 3.0+, field names interning would go away. Ditto should happen if you override JsonFactory.Feature.INTERN_FIELD_NAMES to false. -- Thanks, -Aleksey From shade at redhat.com Mon Nov 4 08:37:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 09:37:10 +0100 Subject: heap memory usage increasing over time with a fixed live set size In-Reply-To: References: <1d366247-c26c-19f7-6234-76b88cbe2077@redhat.com> Message-ID: On 11/3/19 8:43 AM, Amir Hadadi wrote: > Once concurrent class unloading is incorporated, when will it be triggered? The same way it is triggered now with -XX:+ClassUnloadingWithConcurrentMark. > Evidently running it only on special occasions (e.g. degenerated gc) can become a nasty performance > race to the bottom for certain workloads. Yes, and it is a tricky tradeoff between long-term stability in corner cases (when class unloading is needed to purge f.ex. string table) and latency overheads over all common cases (where class unloading needs to do somewhat heavy stuff during final mark pause). Both cases suck in their own way. > Will it be triggered as if?-XX:+ClassUnloadingWithConcurrentMark was enabled, making this flag a no op? > What are the plans in that respect? The plan is to make class unloading concurrent and always enabled. There is a working version in our sh/jdk staging repo: https://hg.openjdk.java.net/shenandoah/jdk https://builds.shipilev.net/openjdk-shenandoah-jdk/ -- Thanks, -Aleksey From shade at redhat.com Mon Nov 4 09:10:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 10:10:29 +0100 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Message-ID: On 11/2/19 4:07 PM, Zhengyu Gu wrote: > Please review this refactor of Shenandoah load barrier. The goal is to make the barrier structurally > similar cross interpreter, C1 and C2, improve readability and maintainability. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233401 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.00/index.html This is cute patch. *) Typo "non-reference load": 207 // 1: none-reference load, no additional barrier is needed *) The comment style is inconsistent with other places: 537 Node* ShenandoahBarrierSetC2::load_at_resolved(C2Access& access, const Type* val_type) const { 538 // 1: load reference 539 Node* load = BarrierSetC2::load_at_resolved(access, val_type); 540 // For none-reference load, no additional barrier is needed *) In constructions like this, it seems more consistent to introduce the local variable for matching the decorator? 387 // Native barrier is for concurrent root processing 388 if (((decorators & IN_NATIVE) != 0) && 389 ShenandoahConcurrentRoots::can_do_concurrent_roots()) { Otherwise looks good. Roman needs to take a look as well. -- Thanks, -Aleksey From aph at redhat.com Mon Nov 4 09:44:34 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Nov 2019 09:44:34 +0000 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Message-ID: On 11/2/19 3:07 PM, Zhengyu Gu wrote: > Please review this refactor of Shenandoah load barrier. The goal is to > make the barrier structurally similar cross interpreter, C1 and C2, > improve readability and maintainability. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233401 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.00/index.html > > Test: > hotspot_gc_shenandoah (fastdebug and release) > x86_64 and x86_32 on Linux > AArch64 on Linux Thanks, this is an improvement. However, it's still weird. // // Arguments: // // Inputs: // src: oop location to load from, might be clobbered // tmp1: unused // tmp_thread: unused // // Output: // dst: oop loaded from src location // // Kill: // rscratch1 (scratch reg) // // Alias: // dst: rscratch1 (might use rscratch1 as temporary output register to avoid clobbering src) // void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, Register dst, Address src, Register tmp1, Register tmp_thread) { tmp1 and tmp_thread are unused? It'd be a good idea, then, to say if they are safe to use or not. Or maybe even better do this if you want to keep the same arg list: void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, Register dst, Address src, Register, Register) { I guess it really isn't safe to use "tmp1" as a tmp, regardless of its name. If so, better pass it as noreg/ -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Nov 4 10:36:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 11:36:34 +0100 Subject: [8] RFR: Fix naked heap loads in HeapDumper Message-ID: <9dfdb951-98ab-4550-4df6-bffdb892e46b@redhat.com> Trivial thing for sh/jdk8, follows what JDK-8199328 is doing: diff -r a56f86355f8d src/share/vm/services/heapDumper.cpp --- a/src/share/vm/services/heapDumper.cpp Thu Oct 31 12:50:02 2019 +0100 +++ b/src/share/vm/services/heapDumper.cpp Mon Nov 04 11:35:57 2019 +0100 @@ -720,10 +720,16 @@ o = oopDesc::load_decode_heap_oop((narrowOop*)addr); } else { o = oopDesc::load_decode_heap_oop((oop*)addr); } +#if INCLUDE_ALL_GCS + if (UseShenandoahGC) { + o = ShenandoahBarrierSet::barrier_set()->load_reference_barrier(o); + } +#endif + // reflection and sun.misc.Unsafe classes may have a reference to a // Klass* so filter it out. assert(o->is_oop_or_null(), "should always be an oop"); writer->write_objectID(o); break; Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From shade at redhat.com Mon Nov 4 11:08:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 12:08:56 +0100 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: Message-ID: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> On 11/1/19 10:50 PM, Aleksey Shipilev wrote: > On 11/1/19 9:21 PM, Alexander Yakushev wrote: >> This happened two times today as I increased the load on the process. >> Here's a piece of the error file: >> https://gist.github.com/alexander-yakushev/828617521ab0368d7bff854745f1fec8. >> I can't share all of it, unfortunately, but I will try to make a >> lightweight reproducible case > > Yes, MCVE would be very handy. > >> Hope this helps, I will try to provide more context if necessary. > > Full hs_err; fastdebug build; +ShenandoahVerify -- or any combination of the above would help. I tried a few combinations of Netty, jcstress and adhoc tests with advanced verification, and still cannot reproduce it. Can you send me the full hs_err somehow? -- Thanks, -Aleksey From shade at redhat.com Mon Nov 4 11:28:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 12:28:02 +0100 Subject: [8] RFR: Fix ifdef -> if INCLUDE_ALL_GCS in Shenandoah x86_32 code Message-ID: <9229358e-c360-1121-026d-b6eb0540a069@redhat.com> Little follow-up in sh/jdk8: I messed up by using #ifdef instead of #if. This is not catastrophic so far, but it exposes UseShenandoahGC blocks unnecessarily. Fix: diff -r 37548f3acb7c src/cpu/x86/vm/stubGenerator_x86_32.cpp --- a/src/cpu/x86/vm/stubGenerator_x86_32.cpp Mon Nov 04 12:03:31 2019 +0100 +++ b/src/cpu/x86/vm/stubGenerator_x86_32.cpp Mon Nov 04 12:25:35 2019 +0100 @@ -39,4 +39,5 @@ #include "runtime/stubRoutines.hpp" #include "runtime/thread.inline.hpp" +#include "utilities/macros.hpp" #include "utilities/top.hpp" #ifdef COMPILER2 @@ -1487,5 +1488,5 @@ __ movptr(to_element_addr, elem); // store the oop __ increment(count); // increment the count toward zero -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Shenandoah barrier is too big for 8-bit offsets to work @@ -1497,5 +1498,5 @@ // ======== loop entry is here ======== __ BIND(L_load_element); -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Needs GC barriers @@ -1505,5 +1506,5 @@ __ movptr(elem, from_element_addr); // load the oop __ testptr(elem, elem); -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Shenandoah barrier is too big for 8-bit offsets to work diff -r 37548f3acb7c src/cpu/x86/vm/templateInterpreter_x86_32.cpp --- a/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Mon Nov 04 12:03:31 2019 +0100 +++ b/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Mon Nov 04 12:25:35 2019 +0100 @@ -748,5 +748,5 @@ __ bind(notChar); -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { Label notObj; @@ -854,5 +854,5 @@ // Load the value of the referent field. const Address field_address(rax, referent_offset); -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Needs GC barriers diff -r 37548f3acb7c src/cpu/x86/vm/templateTable_x86_32.cpp --- a/src/cpu/x86/vm/templateTable_x86_32.cpp Mon Nov 04 12:03:31 2019 +0100 +++ b/src/cpu/x86/vm/templateTable_x86_32.cpp Mon Nov 04 12:25:35 2019 +0100 @@ -670,5 +670,5 @@ index_check(rdx, rax); // kills rbx, // rax,: index -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Needs GC barriers @@ -2312,5 +2312,5 @@ __ jcc(Assembler::notEqual, notObj); -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Needs GC barriers @@ -2887,5 +2887,5 @@ case Bytecodes::_fast_dgetfield: __ fld_d(lo); break; case Bytecodes::_fast_agetfield: -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Needs GC barriers @@ -2921,5 +2921,5 @@ __ movl(rax, lo); } else if (state == atos) { -#ifdef INCLUDE_ALL_GCS +#if INCLUDE_ALL_GCS if (UseShenandoahGC) { // Needs GC barriers Testing: x86_32 hotspot_gc_shenandoah; minimal1 build -- Thanks, -Aleksey From rkennke at redhat.com Mon Nov 4 12:42:19 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 13:42:19 +0100 Subject: [8] RFR: Fix naked heap loads in HeapDumper In-Reply-To: <9dfdb951-98ab-4550-4df6-bffdb892e46b@redhat.com> References: <9dfdb951-98ab-4550-4df6-bffdb892e46b@redhat.com> Message-ID: Yes, please. Thanks, Roman > Trivial thing for sh/jdk8, follows what JDK-8199328 is doing: > > diff -r a56f86355f8d src/share/vm/services/heapDumper.cpp > --- a/src/share/vm/services/heapDumper.cpp Thu Oct 31 12:50:02 2019 +0100 > +++ b/src/share/vm/services/heapDumper.cpp Mon Nov 04 11:35:57 2019 +0100 > @@ -720,10 +720,16 @@ > o = oopDesc::load_decode_heap_oop((narrowOop*)addr); > } else { > o = oopDesc::load_decode_heap_oop((oop*)addr); > } > > +#if INCLUDE_ALL_GCS > + if (UseShenandoahGC) { > + o = ShenandoahBarrierSet::barrier_set()->load_reference_barrier(o); > + } > +#endif > + > // reflection and sun.misc.Unsafe classes may have a reference to a > // Klass* so filter it out. > assert(o->is_oop_or_null(), "should always be an oop"); > writer->write_objectID(o); > break; > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From rkennke at redhat.com Mon Nov 4 13:15:30 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 14:15:30 +0100 Subject: [8] RFR: Fix ifdef -> if INCLUDE_ALL_GCS in Shenandoah x86_32 code In-Reply-To: <9229358e-c360-1121-026d-b6eb0540a069@redhat.com> References: <9229358e-c360-1121-026d-b6eb0540a069@redhat.com> Message-ID: <08ee55c7-eba4-7ddd-bfc3-3d867b820a14@redhat.com> Yes, good! Thanks, Roman > Little follow-up in sh/jdk8: I messed up by using #ifdef instead of #if. This is not catastrophic so > far, but it exposes UseShenandoahGC blocks unnecessarily. > > Fix: > > diff -r 37548f3acb7c src/cpu/x86/vm/stubGenerator_x86_32.cpp > --- a/src/cpu/x86/vm/stubGenerator_x86_32.cpp Mon Nov 04 12:03:31 2019 +0100 > +++ b/src/cpu/x86/vm/stubGenerator_x86_32.cpp Mon Nov 04 12:25:35 2019 +0100 > @@ -39,4 +39,5 @@ > #include "runtime/stubRoutines.hpp" > #include "runtime/thread.inline.hpp" > +#include "utilities/macros.hpp" > #include "utilities/top.hpp" > #ifdef COMPILER2 > @@ -1487,5 +1488,5 @@ > __ movptr(to_element_addr, elem); // store the oop > __ increment(count); // increment the count toward zero > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Shenandoah barrier is too big for 8-bit offsets to work > @@ -1497,5 +1498,5 @@ > // ======== loop entry is here ======== > __ BIND(L_load_element); > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Needs GC barriers > @@ -1505,5 +1506,5 @@ > __ movptr(elem, from_element_addr); // load the oop > __ testptr(elem, elem); > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Shenandoah barrier is too big for 8-bit offsets to work > diff -r 37548f3acb7c src/cpu/x86/vm/templateInterpreter_x86_32.cpp > --- a/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Mon Nov 04 12:03:31 2019 +0100 > +++ b/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Mon Nov 04 12:25:35 2019 +0100 > @@ -748,5 +748,5 @@ > __ bind(notChar); > > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > Label notObj; > @@ -854,5 +854,5 @@ > // Load the value of the referent field. > const Address field_address(rax, referent_offset); > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Needs GC barriers > diff -r 37548f3acb7c src/cpu/x86/vm/templateTable_x86_32.cpp > --- a/src/cpu/x86/vm/templateTable_x86_32.cpp Mon Nov 04 12:03:31 2019 +0100 > +++ b/src/cpu/x86/vm/templateTable_x86_32.cpp Mon Nov 04 12:25:35 2019 +0100 > @@ -670,5 +670,5 @@ > index_check(rdx, rax); // kills rbx, > // rax,: index > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Needs GC barriers > @@ -2312,5 +2312,5 @@ > __ jcc(Assembler::notEqual, notObj); > > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Needs GC barriers > @@ -2887,5 +2887,5 @@ > case Bytecodes::_fast_dgetfield: __ fld_d(lo); break; > case Bytecodes::_fast_agetfield: > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Needs GC barriers > @@ -2921,5 +2921,5 @@ > __ movl(rax, lo); > } else if (state == atos) { > -#ifdef INCLUDE_ALL_GCS > +#if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > // Needs GC barriers > > Testing: x86_32 hotspot_gc_shenandoah; minimal1 build > From shade at redhat.com Mon Nov 4 13:16:15 2019 From: shade at redhat.com (shade at redhat.com) Date: Mon, 04 Nov 2019 13:16:15 +0000 Subject: hg: shenandoah/jdk8/hotspot: 2 new changesets Message-ID: <201911041316.xA4DGFAs006009@aojmv0008.oracle.com> Changeset: 37548f3acb7c Author: shade Date: 2019-11-04 12:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/37548f3acb7c Fix naked heap loads in HeapDumper ! src/share/vm/services/heapDumper.cpp Changeset: e8582ad276a2 Author: shade Date: 2019-11-04 12:25 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e8582ad276a2 Fix ifdef -> if INCLUDE_ALL_GCS in Shenandoah x86_32 code ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp From zgu at redhat.com Mon Nov 4 14:08:42 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 09:08:42 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Message-ID: Hi Andrew, Thanks for the review. > void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, > Register dst, Address src, Register tmp1, Register tmp_thread) { > > tmp1 and tmp_thread are unused? It'd be a good idea, then, to say if they are > safe to use or not. Or maybe even better do this if you want to keep the same > arg list: > > void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, > Register dst, Address src, Register, Register) { > This is an overrode method. What you get for tmp1 and tmp_thread, is really platform dependent. On AArch64, you usually get noreg for tmp1 and tmp_thread. I can not tell if you can safely use tmp1 if it is valid. I don't use tmp1 here, since I don't think it is worth the trouble, as we have spare scratch registers. I do use tmp1 in x86 through. What do you suggest the comment should be? Thanks, -Zhengyu > I guess it really isn't safe to use "tmp1" as a tmp, regardless of its name. > > If so, better pass it as noreg/ > From aph at redhat.com Mon Nov 4 14:32:36 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Nov 2019 14:32:36 +0000 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Message-ID: <6ff66df6-cba8-e2a3-30ba-0ba5656e15fb@redhat.com> On 11/4/19 2:08 PM, Zhengyu Gu wrote: > >> void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, >> Register dst, Address src, Register tmp1, Register tmp_thread) { >> >> tmp1 and tmp_thread are unused? It'd be a good idea, then, to say if they are >> safe to use or not. Or maybe even better do this if you want to keep the same >> arg list: >> >> void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, >> Register dst, Address src, Register, Register) { >> > > This is an overrode method. What you get for tmp1 and tmp_thread, is > really platform dependent. > > On AArch64, you usually get noreg for tmp1 and tmp_thread. I can not > tell if you can safely use tmp1 if it is valid. > > I don't use tmp1 here, since I don't think it is worth the trouble, as > we have spare scratch registers. I do use tmp1 in x86 through. OK, so please just do this for now: >> void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, >> Register dst, Address src, Register, Register) { I'm working on a redesign of the way that scratch registers are used in AArch64, and this code is likely to have to be changed. Accurate information about register usage is likely to be crucial for that. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Nov 4 15:35:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 16:35:52 +0100 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Message-ID: >> Please review this refactor of Shenandoah load barrier. The goal is to make the barrier structurally >> similar cross interpreter, C1 and C2, improve readability and maintainability. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233401 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.00/index.html > > This is cute patch. > > *) Typo "non-reference load": > > 207 // 1: none-reference load, no additional barrier is needed > > *) The comment style is inconsistent with other places: > > 537 Node* ShenandoahBarrierSetC2::load_at_resolved(C2Access& access, const Type* val_type) const { > 538 // 1: load reference > 539 Node* load = BarrierSetC2::load_at_resolved(access, val_type); > 540 // For none-reference load, no additional barrier is needed > > *) In constructions like this, it seems more consistent to introduce the local variable for matching > the decorator? > > 387 // Native barrier is for concurrent root processing > 388 if (((decorators & IN_NATIVE) != 0) && > 389 ShenandoahConcurrentRoots::can_do_concurrent_roots()) { > > Otherwise looks good. Roman needs to take a look as well. Yes, otherwise looks good. Thanks, Roman From alex at bytopia.org Mon Nov 4 15:44:37 2019 From: alex at bytopia.org (Alexander Yakushev) Date: Mon, 4 Nov 2019 17:44:37 +0200 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> Message-ID: Hello again! After some time, I finally managed to reproduce the crash in a non-production environment with +ShenandoahVerify. I attach the hs_err file. This was reproduced with a regular shenandoah-jdk8 build. Meanwhile, I've built the application with fastdebug build and will try with that too if necessary. On Mon, 4 Nov 2019 at 13:09, Aleksey Shipilev wrote: > On 11/1/19 10:50 PM, Aleksey Shipilev wrote: > > On 11/1/19 9:21 PM, Alexander Yakushev wrote: > >> This happened two times today as I increased the load on the process. > >> Here's a piece of the error file: > >> > https://gist.github.com/alexander-yakushev/828617521ab0368d7bff854745f1fec8 > . > >> I can't share all of it, unfortunately, but I will try to make a > >> lightweight reproducible case > > > > Yes, MCVE would be very handy. > > > >> Hope this helps, I will try to provide more context if necessary. > > > > Full hs_err; fastdebug build; +ShenandoahVerify -- or any combination of > the above would help. > > I tried a few combinations of Netty, jcstress and adhoc tests with > advanced verification, and still > cannot reproduce it. Can you send me the full hs_err somehow? > > -- > Thanks, > -Aleksey > > From rkennke at redhat.com Mon Nov 4 15:49:24 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 16:49:24 +0100 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> Message-ID: Hi Alexander, Can you upload the hs_err somewhere? I believe the mailing list strips the large attachment. Thanks, Roman > Hello again! After some time, I finally managed to reproduce the crash in a > non-production environment with +ShenandoahVerify. I attach the hs_err file. > > This was reproduced with a regular shenandoah-jdk8 build. Meanwhile, I've > built the application with fastdebug build and will try with that too if > necessary. > > On Mon, 4 Nov 2019 at 13:09, Aleksey Shipilev wrote: > >> On 11/1/19 10:50 PM, Aleksey Shipilev wrote: >>> On 11/1/19 9:21 PM, Alexander Yakushev wrote: >>>> This happened two times today as I increased the load on the process. >>>> Here's a piece of the error file: >>>> >> https://gist.github.com/alexander-yakushev/828617521ab0368d7bff854745f1fec8 >> . >>>> I can't share all of it, unfortunately, but I will try to make a >>>> lightweight reproducible case >>> >>> Yes, MCVE would be very handy. >>> >>>> Hope this helps, I will try to provide more context if necessary. >>> >>> Full hs_err; fastdebug build; +ShenandoahVerify -- or any combination of >> the above would help. >> >> I tried a few combinations of Netty, jcstress and adhoc tests with >> advanced verification, and still >> cannot reproduce it. Can you send me the full hs_err somehow? >> >> -- >> Thanks, >> -Aleksey >> >> From rkennke at redhat.com Mon Nov 4 15:54:10 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 16:54:10 +0100 Subject: [aarch64-port-dev ] [8u] 8231366: Shenandoah: Shenandoah String Dedup thread is not properly initialized In-Reply-To: References: Message-ID: Looks good to me. Thanks, Roman > This bug seems to exist since day one of 8u backport. The > ConcurrentGCThread API is different in 8u and we leave > ShenandoahDedupThread not properly initialized before it enters work loop. > > In Shenandoah String Deduplication tests, the bug results assertion > failure that shows Thread::current() == NULL. > > The bug only manifests on Windows, is due to discrepancy of java_start() > implementation on different OSs. e.g. it sets *thread* on Linux. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231366 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231366/webrev.00/ > > Test: > ? hotspot_gc_shenandoah on Windows and Linux. > > Thanks, > > -Zhengyu > From shade at redhat.com Mon Nov 4 16:33:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 17:33:30 +0100 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> Message-ID: <8ee880f9-bc96-4349-c13f-b433fa746ad8@redhat.com> On 11/4/19 4:44 PM, Alexander Yakushev wrote: > Hello again! After some time, I finally managed to reproduce the crash in a non-production > environment with?+ShenandoahVerify. I attach the hs_err file. Thanks. I notice that you are running in the unusual configuration: -Xmx12g -Xms12g -XX:ObjectAlignmentInBytes=16 Alignment to 16 bytes is not needed for the heap this small, and it just wastes memory. We are trying to see if that could be the source of bugs too... > This was reproduced with a regular shenandoah-jdk8 build. Meanwhile, I've built the application with > fastdebug build and will try with that too if necessary. Yes, that would be handy. The current hs_err does not yield interesting failure, it seems to be NULL dereference somewhere ObjectMonitor code -- which may or may not be the GC fault. Need to meditate on this a little bit... -- Thanks, -Aleksey From zgu at redhat.com Mon Nov 4 16:55:59 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 11:55:59 -0500 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 Message-ID: This bug was found and fixed during concurrent class unloading work in shenandoah/jdk. However, I don't think it is concurrent class unloading specific issue, and could result hard to find problem in jdk/jdk. BTW: AArch64 already does right thing. Bug: https://bugs.openjdk.java.net/browse/JDK-8233500 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233500/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) x86_64 and x86_32 on Linux Thanks, -Zhengyu From alex at bytopia.org Mon Nov 4 17:01:21 2019 From: alex at bytopia.org (Alexander Yakushev) Date: Mon, 4 Nov 2019 19:01:21 +0200 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: <8ee880f9-bc96-4349-c13f-b433fa746ad8@redhat.com> References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> <8ee880f9-bc96-4349-c13f-b433fa746ad8@redhat.com> Message-ID: The object alignment part is most probably not the cause of this. The error log I sent you is from a QA machine which is smaller, so I reduce -Xmx there while keeping the rest of the options unchanged (including object alignment). In production (where the crash originally happened), the heap is set to 62g. Regarding the fastdebug build, this will take a bit longer. Fastdebug build is so slow that the application can't even start in time to not be killed by the load balancer healthchecks:). I'll repat the experiment tomorrow. On Mon, 4 Nov 2019 at 18:33, Aleksey Shipilev wrote: > On 11/4/19 4:44 PM, Alexander Yakushev wrote: > > Hello again! After some time, I finally managed to reproduce the crash > in a non-production > > environment with +ShenandoahVerify. I attach the hs_err file. > > Thanks. I notice that you are running in the unusual configuration: > -Xmx12g -Xms12g -XX:ObjectAlignmentInBytes=16 > > Alignment to 16 bytes is not needed for the heap this small, and it just > wastes memory. > > We are trying to see if that could be the source of bugs too... > > > This was reproduced with a regular shenandoah-jdk8 build. Meanwhile, > I've built the application with > > fastdebug build and will try with that too if necessary. > > Yes, that would be handy. The current hs_err does not yield interesting > failure, it seems to be NULL > dereference somewhere ObjectMonitor code -- which may or may not be the GC > fault. Need to meditate > on this a little bit... > > -- > Thanks, > -Aleksey > > From shade at redhat.com Mon Nov 4 17:07:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 18:07:58 +0100 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: References: Message-ID: On 11/4/19 5:55 PM, Zhengyu Gu wrote: > This bug was found and fixed during concurrent class unloading work in shenandoah/jdk. However, I > don't think it is concurrent class unloading specific issue, and could result hard to find problem > in jdk/jdk. > > BTW: AArch64 already does right thing. Where? Please be specific when saying this (i.e. point to code), for archival reasons. > Bug: https://bugs.openjdk.java.net/browse/JDK-8233500 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233500/webrev.00/ I don't understand this. SATB handling is similar to G1 is doing, where's the similar code in G1? The patch adds save/restore at in SBSA::load_at, but there is a similar block in SBSA::store_at, why it is not needed there? -- Thanks, -Aleksey From zgu at redhat.com Mon Nov 4 17:32:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 12:32:11 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <6ff66df6-cba8-e2a3-30ba-0ba5656e15fb@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <6ff66df6-cba8-e2a3-30ba-0ba5656e15fb@redhat.com> Message-ID: >> On AArch64, you usually get noreg for tmp1 and tmp_thread. I can not >> tell if you can safely use tmp1 if it is valid. >> >> I don't use tmp1 here, since I don't think it is worth the trouble, as >> we have spare scratch registers. I do use tmp1 in x86 through. > > OK, so please just do this for now: Thanks! -Zhengyu > >>> void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, >>> Register dst, Address src, Register, Register) { > > I'm working on a redesign of the way that scratch registers are used in > AArch64, and this code is likely to have to be changed. Accurate information > about register usage is likely to be crucial for that. > From zgu at redhat.com Mon Nov 4 17:33:20 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 12:33:20 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> Message-ID: <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.01/index.html Okay now? Thanks, -Zhengyu On 11/4/19 10:35 AM, Roman Kennke wrote: >>> Please review this refactor of Shenandoah load barrier. The goal is to make the barrier structurally >>> similar cross interpreter, C1 and C2, improve readability and maintainability. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233401 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.00/index.html >> >> This is cute patch. >> >> *) Typo "non-reference load": >> >> 207 // 1: none-reference load, no additional barrier is needed >> >> *) The comment style is inconsistent with other places: >> >> 537 Node* ShenandoahBarrierSetC2::load_at_resolved(C2Access& access, const Type* val_type) const { >> 538 // 1: load reference >> 539 Node* load = BarrierSetC2::load_at_resolved(access, val_type); >> 540 // For none-reference load, no additional barrier is needed >> >> *) In constructions like this, it seems more consistent to introduce the local variable for matching >> the decorator? >> >> 387 // Native barrier is for concurrent root processing >> 388 if (((decorators & IN_NATIVE) != 0) && >> 389 ShenandoahConcurrentRoots::can_do_concurrent_roots()) { >> >> Otherwise looks good. Roman needs to take a look as well. > > Yes, otherwise looks good. > > Thanks, > Roman > > From aph at redhat.com Mon Nov 4 17:38:14 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Nov 2019 17:38:14 +0000 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> Message-ID: <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> On 11/4/19 5:33 PM, Zhengyu Gu wrote: > Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.01/index.html > > Okay now? AArch64 still says void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, Register dst, Address src, Register tmp1, Register tmp_thread) { instead of void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, Register dst, Address src, Register, Register) { -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Nov 4 17:47:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 18:47:24 +0100 Subject: RFR (S) 8233520: Shenandoah: do not sleep when thread is attaching Message-ID: <04f22413-4d71-7a63-85e5-563b13710aa2@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8233520 Fix: http://cr.openjdk.java.net/~shade/8233520/webrev.01/ This was exposed by recently added assert. But the bug itself is legit Shenandoah bug, and should be fixed everywhere. Testing: affected test; hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Mon Nov 4 18:18:38 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 13:18:38 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> Message-ID: <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> On 11/4/19 12:38 PM, Andrew Haley wrote: > On 11/4/19 5:33 PM, Zhengyu Gu wrote: >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.01/index.html >> >> Okay now? > AArch64 still says > > void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, > Register dst, Address src, Register tmp1, Register tmp_thread) { > > instead of > > void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, > Register dst, Address src, Register, Register) { They are still needed for calling super class's load_at(). Even though, they are not used there neither. // 1: non-reference load, no additional barrier is needed if (!is_reference_type(type) ) { BarrierSetAssembler::load_at(masm, decorators, type, dst, src, tmp1, tmp_thread); return; } -Zhengyu > From zgu at redhat.com Mon Nov 4 18:23:12 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 13:23:12 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> Message-ID: <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> On 11/4/19 1:18 PM, Zhengyu Gu wrote: > > > On 11/4/19 12:38 PM, Andrew Haley wrote: >> On 11/4/19 5:33 PM, Zhengyu Gu wrote: >>> Updated: >>> http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.01/index.html >>> >>> Okay now? >> AArch64 still says >> >> ? void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, >> DecoratorSet decorators, BasicType type, >> ????????????????????????????????????????????? Register dst, Address >> src, Register tmp1, Register tmp_thread) { >> >> instead of >> >> ? void ShenandoahBarrierSetAssembler::load_at(MacroAssembler* masm, >> DecoratorSet decorators, BasicType type, >> ????????????????????????????????????????????? Register dst, Address >> src, Register, Register) { > > They are still needed for calling super class's load_at(). Even though, > they are not used there neither. Or I should say, they are not used there right now, but may be used in future ... -Zhengyu > > ? // 1: non-reference load, no additional barrier is needed > ? if (!is_reference_type(type) ) { > ??? BarrierSetAssembler::load_at(masm, decorators, type, dst, src, > tmp1, tmp_thread); > ??? return; > ? } > > > -Zhengyu > >> From rkennke at redhat.com Mon Nov 4 18:23:51 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 19:23:51 +0100 Subject: RFR (S) 8233520: Shenandoah: do not sleep when thread is attaching In-Reply-To: <04f22413-4d71-7a63-85e5-563b13710aa2@redhat.com> References: <04f22413-4d71-7a63-85e5-563b13710aa2@redhat.com> Message-ID: <31515f5f-505d-4bfb-8105-9ffcf86870da@redhat.com> Ok. Thanks, Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8233520 > > Fix: > http://cr.openjdk.java.net/~shade/8233520/webrev.01/ > > This was exposed by recently added assert. But the bug itself is legit Shenandoah bug, and should be > fixed everywhere. > > Testing: affected test; hotspot_gc_shenandoah > From shade at redhat.com Mon Nov 4 18:26:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 19:26:19 +0100 Subject: [8] RFR: Cherry-pick JDK-8231201: hs_err should print coalesced safepoint operations in Events section Message-ID: <6b8689d4-e6a0-3eaf-ad2a-69a873a38fde@redhat.com> Looking at hs_errs from Alexander, I suspect there are more VM operations happening than meets the eye. See for example: Event: 749.332 Executing VM operation: FindDeadlocks Event: 749.333 Pause Init Update Refs Event: 751.083 Pause Init Update Refs done Event: 751.083 Executing VM operation: FindDeadlocks done Where's the "Executing VM operation: ShenandoahInitUpdateRefs"? The answer is here: https://bugs.openjdk.java.net/browse/JDK-8231201 I requested the jdk8u backport here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010552.html ...but it would be a while before it lands in sh/jdk8. So, let's cherry-pick it: diff -r e8582ad276a2 src/share/vm/runtime/vmThread.cpp --- a/src/share/vm/runtime/vmThread.cpp Mon Nov 04 12:25:21 2019 +0100 +++ b/src/share/vm/runtime/vmThread.cpp Mon Nov 04 19:23:12 2019 +0100 @@ -505,10 +505,11 @@ // the queue until there are none left do { _cur_vm_operation = safepoint_ops; if (_cur_vm_operation != NULL) { do { + EventMark em("Executing coalesced VM operation: %s", _cur_vm_operation->name()); // evaluate_operation deletes the op object so we have // to grab the next op now VM_Operation* next = _cur_vm_operation->next(); _vm_queue->set_drain_list(next); evaluate_operation(_cur_vm_operation); Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Mon Nov 4 18:34:45 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 13:34:45 -0500 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: References: Message-ID: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> On 11/4/19 12:07 PM, Aleksey Shipilev wrote: > On 11/4/19 5:55 PM, Zhengyu Gu wrote: >> This bug was found and fixed during concurrent class unloading work in shenandoah/jdk. However, I >> don't think it is concurrent class unloading specific issue, and could result hard to find problem >> in jdk/jdk. >> >> BTW: AArch64 already does right thing. > > Where? Please be specific when saying this (i.e. point to code), for archival reasons. http://hg.openjdk.java.net/jdk/jdk/file/33f9271b3167/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp#l383 > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233500 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233500/webrev.00/ > > I don't understand this. > > SATB handling is similar to G1 is doing, where's the similar code in G1? The patch adds save/restore > at in SBSA::load_at, but there is a similar block in SBSA::store_at, why it is not needed there? Because we do self-fixing in LRB and have to reshuffle registers. Not sure about SBSA::store_at(), because it still similar to G1 code? Thanks, -Zhengyu > From shade at redhat.com Mon Nov 4 18:39:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Nov 2019 19:39:33 +0100 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> References: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> Message-ID: On 11/4/19 7:34 PM, Zhengyu Gu wrote: >> SATB handling is similar to G1 is doing, where's the similar code in G1? The patch adds save/restore >> at in SBSA::load_at, but there is a similar block in SBSA::store_at, why it is not needed there? > > Because we do self-fixing in LRB and have to reshuffle registers. Okay. So AArch64 does enter()/leave(), why x86 needs the entire IU_state pushed/popped? My concern is that pushing/popping the entire state explodes code size (we don't care about performance much, but we do care about hitting the stub boundaries), and probably hides some bugs with register shuffles. -- Thanks, -Aleksey From zgu at redhat.com Mon Nov 4 18:42:19 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 13:42:19 -0500 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: References: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> Message-ID: <4719fe38-c2be-bfe6-13a5-a2b050c7796e@redhat.com> On 11/4/19 1:39 PM, Aleksey Shipilev wrote: > On 11/4/19 7:34 PM, Zhengyu Gu wrote: >>> SATB handling is similar to G1 is doing, where's the similar code in G1? The patch adds save/restore >>> at in SBSA::load_at, but there is a similar block in SBSA::store_at, why it is not needed there? >> >> Because we do self-fixing in LRB and have to reshuffle registers. > > Okay. So AArch64 does enter()/leave(), why x86 needs the entire IU_state pushed/popped? Roman suggested. Roman, could you answer? Thanks, -Zhengyu > > My concern is that pushing/popping the entire state explodes code size (we don't care about > performance much, but we do care about hitting the stub boundaries), and probably hides some bugs > with register shuffles. > From rkennke at redhat.com Mon Nov 4 18:59:14 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Nov 2019 19:59:14 +0100 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: <4719fe38-c2be-bfe6-13a5-a2b050c7796e@redhat.com> References: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> <4719fe38-c2be-bfe6-13a5-a2b050c7796e@redhat.com> Message-ID: <3dbf88b0-5de6-a2b9-93b5-086927e88f82@redhat.com> >>>> SATB handling is similar to G1 is doing, where's the similar code in >>>> G1? The patch adds save/restore >>>> at in SBSA::load_at, but there is a similar block in SBSA::store_at, >>>> why it is not needed there? >>> >>> Because we do self-fixing in LRB and have to reshuffle registers. >> >> Okay. So AArch64 does enter()/leave(), why x86 needs the entire >> IU_state pushed/popped? > Roman suggested. > > Roman, could you answer? enter()/leave() sets up/tears down the stub frame for the runtime call. push/pop_IU_state() saves/restores the registers. Aarch64 code also saves/restores the registers via push/pop_call_clobbered_registers(). Roman > Thanks, > > -Zhengyu > >> >> My concern is that pushing/popping the entire state explodes code size >> (we don't care about >> performance much, but we do care about hitting the stub boundaries), >> and probably hides some bugs >> with register shuffles. >> From zgu at redhat.com Mon Nov 4 19:12:35 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 Nov 2019 14:12:35 -0500 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: <3dbf88b0-5de6-a2b9-93b5-086927e88f82@redhat.com> References: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> <4719fe38-c2be-bfe6-13a5-a2b050c7796e@redhat.com> <3dbf88b0-5de6-a2b9-93b5-086927e88f82@redhat.com> Message-ID: On 11/4/19 1:59 PM, Roman Kennke wrote: >>>>> SATB handling is similar to G1 is doing, where's the similar code in >>>>> G1? The patch adds save/restore >>>>> at in SBSA::load_at, but there is a similar block in SBSA::store_at, >>>>> why it is not needed there? >>>> >>>> Because we do self-fixing in LRB and have to reshuffle registers. >>> >>> Okay. So AArch64 does enter()/leave(), why x86 needs the entire >>> IU_state pushed/popped? >> Roman suggested. >> >> Roman, could you answer? > > enter()/leave() sets up/tears down the stub frame for the runtime call. Ha, I misunderstood enter()/leave(). > push/pop_IU_state() saves/restores the registers. Aarch64 code also > saves/restores the registers via push/pop_call_clobbered_registers(). I think we are still okay with AArch64, because unlike x86, it at most clobbers rscratch1. -Zhengyu > > Roman > > >> Thanks, >> >> -Zhengyu >> >>> >>> My concern is that pushing/popping the entire state explodes code size >>> (we don't care about >>> performance much, but we do care about hitting the stub boundaries), >>> and probably hides some bugs >>> with register shuffles. >>> > From aph at redhat.com Tue Nov 5 08:52:20 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Nov 2019 08:52:20 +0000 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> Message-ID: <6c110878-a477-df8a-e566-84b113806044@redhat.com> On 11/4/19 6:23 PM, Zhengyu Gu wrote: >> They are still needed for calling super class's load_at(). Even though, >> they are not used there neither. Aha! Sorry, I missed that. > Or I should say, they are not used there right now, but may be used in > future ... So add them in the future, surely. All you're doing by passing unused args is confusing the reader. It definitely succeeded with me... -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Nov 5 09:58:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Nov 2019 10:58:21 +0100 Subject: [11] RFR: 2019-11-05, Follow-up backports to sh/jdk11 In-Reply-To: References: Message-ID: <140c3c79-14c6-4826-4f8d-dce72675c6a0@redhat.com> On 11/1/19 4:51 PM, Aleksey Shipilev wrote: > I would like to push two follow-up backports to sh/jdk11: > [backport] 8233303: Shenandoah: verifier assert erroneously uses byte_size_in_exact_unit > [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically > > Webrev: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20191101/webrev.01/ Let me add another one into that mix: [backport] 8233520: Shenandoah: do not sleep when thread is attaching Webrev: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20191105/webrev.01/ -- Thanks, -Aleksey From rkennke at redhat.com Tue Nov 5 10:29:21 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Nov 2019 11:29:21 +0100 Subject: [11] RFR: 2019-11-05, Follow-up backports to sh/jdk11 In-Reply-To: <140c3c79-14c6-4826-4f8d-dce72675c6a0@redhat.com> References: <140c3c79-14c6-4826-4f8d-dce72675c6a0@redhat.com> Message-ID: <97501682-7180-0ef5-d6e0-cda770fa1a46@redhat.com> ok! Roman > On 11/1/19 4:51 PM, Aleksey Shipilev wrote: >> I would like to push two follow-up backports to sh/jdk11: >> [backport] 8233303: Shenandoah: verifier assert erroneously uses byte_size_in_exact_unit >> [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically >> >> Webrev: >> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20191101/webrev.01/ > > Let me add another one into that mix: > [backport] 8233520: Shenandoah: do not sleep when thread is attaching > > Webrev: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20191105/webrev.01/ > From shade at redhat.com Tue Nov 5 10:30:30 2019 From: shade at redhat.com (shade at redhat.com) Date: Tue, 05 Nov 2019 10:30:30 +0000 Subject: hg: shenandoah/jdk11: 3 new changesets Message-ID: <201911051030.xA5AUVSh007685@aojmv0008.oracle.com> Changeset: ddecb9b4ef2c Author: shade Date: 2019-10-31 10:37 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ddecb9b4ef2c [backport] 8233303: Shenandoah: verifier assert erroneously uses byte_size_in_exact_unit Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: b44ba55259f5 Author: shade Date: 2019-11-01 16:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b44ba55259f5 [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPassiveMode.cpp Changeset: b8cd9e98adca Author: shade Date: 2019-11-04 19:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b8cd9e98adca [backport] 8233520: Shenandoah: do not sleep when thread is attaching Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp From rkennke at redhat.com Tue Nov 5 10:43:23 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Nov 2019 11:43:23 +0100 Subject: [8] RFR: Cherry-pick JDK-8231201: hs_err should print coalesced safepoint operations in Events section In-Reply-To: <6b8689d4-e6a0-3eaf-ad2a-69a873a38fde@redhat.com> References: <6b8689d4-e6a0-3eaf-ad2a-69a873a38fde@redhat.com> Message-ID: <8e7b4662-a6b2-3cff-c8d6-0f09d9d99b0f@redhat.com> Ok, that makes sense. Do it! Thanks, Roman > Looking at hs_errs from Alexander, I suspect there are more VM operations happening than meets the > eye. See for example: > > Event: 749.332 Executing VM operation: FindDeadlocks > Event: 749.333 Pause Init Update Refs > Event: 751.083 Pause Init Update Refs done > Event: 751.083 Executing VM operation: FindDeadlocks done > > Where's the "Executing VM operation: ShenandoahInitUpdateRefs"? The answer is here: > https://bugs.openjdk.java.net/browse/JDK-8231201 > > I requested the jdk8u backport here: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010552.html > > ...but it would be a while before it lands in sh/jdk8. So, let's cherry-pick it: > > diff -r e8582ad276a2 src/share/vm/runtime/vmThread.cpp > --- a/src/share/vm/runtime/vmThread.cpp Mon Nov 04 12:25:21 2019 +0100 > +++ b/src/share/vm/runtime/vmThread.cpp Mon Nov 04 19:23:12 2019 +0100 > @@ -505,10 +505,11 @@ > // the queue until there are none left > do { > _cur_vm_operation = safepoint_ops; > if (_cur_vm_operation != NULL) { > do { > + EventMark em("Executing coalesced VM operation: %s", _cur_vm_operation->name()); > // evaluate_operation deletes the op object so we have > // to grab the next op now > VM_Operation* next = _cur_vm_operation->next(); > _vm_queue->set_drain_list(next); > evaluate_operation(_cur_vm_operation); > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Tue Nov 5 10:44:35 2019 From: shade at redhat.com (shade at redhat.com) Date: Tue, 05 Nov 2019 10:44:35 +0000 Subject: hg: shenandoah/jdk8/hotspot: Cherry-pick JDK-8231201: hs_err should print coalesced safepoint operations in Events section Message-ID: <201911051044.xA5AiZnA015248@aojmv0008.oracle.com> Changeset: aedd635caddf Author: shade Date: 2019-09-19 09:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/aedd635caddf Cherry-pick JDK-8231201: hs_err should print coalesced safepoint operations in Events section ! src/share/vm/runtime/vmThread.cpp From shade at redhat.com Tue Nov 5 10:45:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Nov 2019 11:45:25 +0100 Subject: [8] RFR: Cherry-pick JDK-8231201: hs_err should print coalesced safepoint operations in Events section In-Reply-To: <8e7b4662-a6b2-3cff-c8d6-0f09d9d99b0f@redhat.com> References: <6b8689d4-e6a0-3eaf-ad2a-69a873a38fde@redhat.com> <8e7b4662-a6b2-3cff-c8d6-0f09d9d99b0f@redhat.com> Message-ID: <91143bc7-11c2-e774-79ac-406294cde917@redhat.com> Pushed; builds are rebuilding. On 11/5/19 11:43 AM, Roman Kennke wrote: > Ok, that makes sense. Do it! > > Thanks, > Roman > >> Looking at hs_errs from Alexander, I suspect there are more VM operations happening than meets the >> eye. See for example: >> >> Event: 749.332 Executing VM operation: FindDeadlocks >> Event: 749.333 Pause Init Update Refs >> Event: 751.083 Pause Init Update Refs done >> Event: 751.083 Executing VM operation: FindDeadlocks done >> >> Where's the "Executing VM operation: ShenandoahInitUpdateRefs"? The answer is here: >> https://bugs.openjdk.java.net/browse/JDK-8231201 >> >> I requested the jdk8u backport here: >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010552.html >> >> ...but it would be a while before it lands in sh/jdk8. So, let's cherry-pick it: >> >> diff -r e8582ad276a2 src/share/vm/runtime/vmThread.cpp >> --- a/src/share/vm/runtime/vmThread.cpp Mon Nov 04 12:25:21 2019 +0100 >> +++ b/src/share/vm/runtime/vmThread.cpp Mon Nov 04 19:23:12 2019 +0100 >> @@ -505,10 +505,11 @@ >> // the queue until there are none left >> do { >> _cur_vm_operation = safepoint_ops; >> if (_cur_vm_operation != NULL) { >> do { >> + EventMark em("Executing coalesced VM operation: %s", _cur_vm_operation->name()); >> // evaluate_operation deletes the op object so we have >> // to grab the next op now >> VM_Operation* next = _cur_vm_operation->next(); >> _vm_queue->set_drain_list(next); >> evaluate_operation(_cur_vm_operation); >> >> Testing: hotspot_gc_shenandoah >> > -- Thanks, -Aleksey From zgu at redhat.com Tue Nov 5 12:33:19 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 5 Nov 2019 07:33:19 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <6c110878-a477-df8a-e566-84b113806044@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> Message-ID: <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> On 11/5/19 3:52 AM, Andrew Haley wrote: > On 11/4/19 6:23 PM, Zhengyu Gu wrote: >>> They are still needed for calling super class's load_at(). Even though, >>> they are not used there neither. > > Aha! Sorry, I missed that. > >> Or I should say, they are not used there right now, but may be used in >> future ... > > So add them in the future, surely. All you're doing by passing unused > args is confusing the reader. It definitely succeeded with me... > Sorry, I should just remove 'unused' comments. Okay with you? Thanks, -Zhengyu From zgu at redhat.com Tue Nov 5 12:50:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 5 Nov 2019 07:50:11 -0500 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: References: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> Message-ID: <0044dc42-1e6b-4e90-fc49-c0cc45d1626f@redhat.com> On 11/4/19 1:39 PM, Aleksey Shipilev wrote: > On 11/4/19 7:34 PM, Zhengyu Gu wrote: >>> SATB handling is similar to G1 is doing, where's the similar code in G1? The patch adds save/restore >>> at in SBSA::load_at, but there is a similar block in SBSA::store_at, why it is not needed there? >> >> Because we do self-fixing in LRB and have to reshuffle registers. > > Okay. So AArch64 does enter()/leave(), why x86 needs the entire IU_state pushed/popped? > > My concern is that pushing/popping the entire state explodes code size (we don't care about > performance much, but we do care about hitting the stub boundaries), and probably hides some bugs > with register shuffles. > push_IU_state()/pop_IU_state(), each adds 3 instructions on x86_64, 2 on x86_32. void MacroAssembler::push_IU_state() { // Push flags first because pusha kills them pushf(); // Make sure rsp stays 16-byte aligned LP64_ONLY(subq(rsp, 8)); pusha(); } void MacroAssembler::pop_IU_state() { popa(); LP64_ONLY(addq(rsp, 8)); popf(); } -Zhengyu From roman at kennke.org Tue Nov 5 14:03:42 2019 From: roman at kennke.org (Roman Kennke) Date: Tue, 05 Nov 2019 15:03:42 +0100 Subject: RFR 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 In-Reply-To: <0044dc42-1e6b-4e90-fc49-c0cc45d1626f@redhat.com> References: <1078cf3a-3d99-4cc3-dd0f-55a63967caa5@redhat.com> <0044dc42-1e6b-4e90-fc49-c0cc45d1626f@redhat.com> Message-ID: <87200AE8-BFF9-4FD4-9F51-595FF7828815@kennke.org> Am 5. November 2019 13:50:11 MEZ schrieb Zhengyu Gu : > > >On 11/4/19 1:39 PM, Aleksey Shipilev wrote: >> On 11/4/19 7:34 PM, Zhengyu Gu wrote: >>>> SATB handling is similar to G1 is doing, where's the similar code >in G1? The patch adds save/restore >>>> at in SBSA::load_at, but there is a similar block in >SBSA::store_at, why it is not needed there? >>> >>> Because we do self-fixing in LRB and have to reshuffle registers. >> >> Okay. So AArch64 does enter()/leave(), why x86 needs the entire >IU_state pushed/popped? >> >> My concern is that pushing/popping the entire state explodes code >size (we don't care about >> performance much, but we do care about hitting the stub boundaries), >and probably hides some bugs >> with register shuffles. >> > >push_IU_state()/pop_IU_state(), each adds 3 instructions on x86_64, 2 >on >x86_32. > > >void MacroAssembler::push_IU_state() { > // Push flags first because pusha kills them > pushf(); > // Make sure rsp stays 16-byte aligned > LP64_ONLY(subq(rsp, 8)); > pusha(); >} > > >void MacroAssembler::pop_IU_state() { > popa(); > LP64_ONLY(addq(rsp, 8)); > popf(); >} > >-Zhengyu Careful there! IIRC pusha() is a macro instruction on x86_64 that expands to 16+ instructions. On the other side, we did examine in the past to reduce instructions there by analysing what the interpreter actually uses and what is required by calling conventions, and yes there are opportunities to reduce number of instructions, but the risk of bugs due to the barrier being called from unusual places, e.g. via C2/cas-obj or outside interpreter (we did have such bugs and they are not fun!) did not make it seem worth. Saving/restoring the entire state seems conservatively save approach. Roman -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From aph at redhat.com Tue Nov 5 16:26:19 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Nov 2019 16:26:19 +0000 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> Message-ID: <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> On 11/5/19 12:33 PM, Zhengyu Gu wrote: > > > On 11/5/19 3:52 AM, Andrew Haley wrote: >> On 11/4/19 6:23 PM, Zhengyu Gu wrote: >>>> They are still needed for calling super class's load_at(). Even though, >>>> they are not used there neither. >> >> Aha! Sorry, I missed that. >> >>> Or I should say, they are not used there right now, but may be used in >>> future ... >> >> So add them in the future, surely. All you're doing by passing unused >> args is confusing the reader. It definitely succeeded with me... >> > Sorry, I should just remove 'unused' comments. Okay with you? OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Wed Nov 6 12:18:28 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 6 Nov 2019 07:18:28 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> Message-ID: <93330192-7143-ca82-9872-fe627a97772e@redhat.com> On 11/5/19 11:26 AM, Andrew Haley wrote: > On 11/5/19 12:33 PM, Zhengyu Gu wrote: >> >> >> On 11/5/19 3:52 AM, Andrew Haley wrote: >>> On 11/4/19 6:23 PM, Zhengyu Gu wrote: >>>>> They are still needed for calling super class's load_at(). Even though, >>>>> they are not used there neither. >>> >>> Aha! Sorry, I missed that. >>> >>>> Or I should say, they are not used there right now, but may be used in >>>> future ... >>> >>> So add them in the future, surely. All you're doing by passing unused >>> args is confusing the reader. It definitely succeeded with me... >>> >> Sorry, I should just remove 'unused' comments. Okay with you? > > OK. Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.02/index.html Thanks, -Zhengyu > From aph at redhat.com Wed Nov 6 12:35:54 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Nov 2019 12:35:54 +0000 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <93330192-7143-ca82-9872-fe627a97772e@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> <93330192-7143-ca82-9872-fe627a97772e@redhat.com> Message-ID: <7e9ace3d-8d15-e87a-f01c-90fc4b6faa6a@redhat.com> On 11/6/19 12:18 PM, Zhengyu Gu wrote: > Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.02/index.html OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Nov 6 13:45:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Nov 2019 14:45:27 +0100 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <93330192-7143-ca82-9872-fe627a97772e@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> <93330192-7143-ca82-9872-fe627a97772e@redhat.com> Message-ID: <7f8dd01f-30f7-f8c9-544a-c06f2a49eea0@redhat.com> On 11/6/19 1:18 PM, Zhengyu Gu wrote: > Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.02/index.html Minor nits: *) shenandoahBarrierSetAssembler_aarch64.cpp: excess space between parentheses: 368 if (!is_reference_type(type) ) { *) shenandoahBarrierSetC1.cpp: so, native oop loads used to call to ShenandoahRuntime::load_reference_barrier_native before this refactoring? That would mean it is enabled even when "passive" is enabled (which implies -ShenandoahLRB)? Current change looks fine, but we need to recognize this is the behavioral change. Please link the issue where that regression was introduced. Otherwise looks fine to me, let Roman ack it too. -- Thanks, -Aleksey From zgu at redhat.com Wed Nov 6 14:15:55 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 6 Nov 2019 09:15:55 -0500 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <7f8dd01f-30f7-f8c9-544a-c06f2a49eea0@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> <93330192-7143-ca82-9872-fe627a97772e@redhat.com> <7f8dd01f-30f7-f8c9-544a-c06f2a49eea0@redhat.com> Message-ID: <0251231d-047e-0117-25b0-8ecfc9b30b7f@redhat.com> Thanks for the review, Aleksey. On 11/6/19 8:45 AM, Aleksey Shipilev wrote: > On 11/6/19 1:18 PM, Zhengyu Gu wrote: >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.02/index.html > > Minor nits: > > *) shenandoahBarrierSetAssembler_aarch64.cpp: excess space between parentheses: > > 368 if (!is_reference_type(type) ) { Will fix before push. > > *) shenandoahBarrierSetC1.cpp: so, native oop loads used to call to > ShenandoahRuntime::load_reference_barrier_native before this refactoring? That would mean it is > enabled even when "passive" is enabled (which implies -ShenandoahLRB)? Current change looks fine, > but we need to recognize this is the behavioral change. Please link the issue where that regression > was introduced. Correct, we don't need load_reference_barrier_native barrier if weak roots are processed at STW pauses. Added comments about this behavioral change in CR and linked to JDK-8227635. -Zhengyu > > Otherwise looks fine to me, let Roman ack it too. > From rkennke at redhat.com Wed Nov 6 14:39:58 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Nov 2019 15:39:58 +0100 Subject: [aarch64-port-dev ] RFR 8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code In-Reply-To: <7e9ace3d-8d15-e87a-f01c-90fc4b6faa6a@redhat.com> References: <45287c04-370c-cb0b-1603-c93fe15da3d9@redhat.com> <87b115fb-5353-b21b-3cbc-f862bd932b3e@redhat.com> <3d70db1c-c927-48f8-23ab-8937838e0302@redhat.com> <0d347d16-f870-798f-0165-1ee4dfae511b@redhat.com> <859e48d6-9af5-b4af-32ac-4b07ce92e94d@redhat.com> <6c110878-a477-df8a-e566-84b113806044@redhat.com> <84394d85-1b99-8139-3baf-7fbedba702c0@redhat.com> <2be52de0-6f12-d989-cf69-5807b2160cb0@redhat.com> <93330192-7143-ca82-9872-fe627a97772e@redhat.com> <7e9ace3d-8d15-e87a-f01c-90fc4b6faa6a@redhat.com> Message-ID: >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8233401/webrev.02/index.html > > OK. Ok too. Roman From claes.redestad at oracle.com Wed Nov 6 14:42:50 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 Nov 2019 15:42:50 +0100 Subject: RFR: 8233708: VectorSet cleanup Message-ID: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> Hi, VectorSet needs a cleanup: - Extravagant use of operator overloading (<<= adds items to the set, >>= removes them :eyeroll:) - Plenty of unused methods - Since VectorSet is the only implementation in the code base, the abstract base class Set is unnecessary - Various method names in conflict with HotSpot code "standard" Webrev: http://cr.openjdk.java.net/~redestad/8233708/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8233708 Testing: tier1-3, built and sanity tested with Shenandoah due changes in some Shenandoah C2 support Thanks! /Claes From shade at redhat.com Wed Nov 6 15:49:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Nov 2019 16:49:26 +0100 Subject: RFR: 8233708: VectorSet cleanup In-Reply-To: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> References: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> Message-ID: <336853d7-3047-0194-4e36-9ee968e07a86@redhat.com> On 11/6/19 3:42 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8233708/open.00/ Shenandoah part looks fine. The rest looks fine too. -- Thanks, -Aleksey From tobias.hartmann at oracle.com Wed Nov 6 15:57:13 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 6 Nov 2019 16:57:13 +0100 Subject: RFR: 8233708: VectorSet cleanup In-Reply-To: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> References: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> Message-ID: Hi Claes, very nice. While you're at it, could you add brackets to the for-loops/ifs in vectset.cpp:70, vectset.hpp:89, 98 and fix the whitespacing? No new webrev required. Thanks, Tobias On 06.11.19 15:42, Claes Redestad wrote: > Hi, > > VectorSet needs a cleanup: > > - Extravagant use of operator overloading (<<= adds items to the set, >>>= removes them :eyeroll:) > - Plenty of unused methods > - Since VectorSet is the only implementation in the code base, the > abstract base class Set is unnecessary > - Various method names in conflict with HotSpot code "standard" > > Webrev: http://cr.openjdk.java.net/~redestad/8233708/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8233708 > > Testing: tier1-3, built and sanity tested with Shenandoah due changes > in some Shenandoah C2 support > > Thanks! > > /Claes From claes.redestad at oracle.com Wed Nov 6 19:17:16 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 Nov 2019 20:17:16 +0100 Subject: RFR: 8233708: VectorSet cleanup In-Reply-To: <336853d7-3047-0194-4e36-9ee968e07a86@redhat.com> References: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> <336853d7-3047-0194-4e36-9ee968e07a86@redhat.com> Message-ID: <5af59bb9-6d1a-1a69-0693-a27ee9a2d56c@oracle.com> Hi Aleksey, On 2019-11-06 16:49, Aleksey Shipilev wrote: > On 11/6/19 3:42 PM, Claes Redestad wrote: >> Webrev: http://cr.openjdk.java.net/~redestad/8233708/open.00/ > > Shenandoah part looks fine. thanks for checking! > > The rest looks fine too. Thanks! /Claes From claes.redestad at oracle.com Wed Nov 6 19:18:01 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 Nov 2019 20:18:01 +0100 Subject: RFR: 8233708: VectorSet cleanup In-Reply-To: References: <641814b2-3b10-06d6-39f8-b02d096832b5@oracle.com> Message-ID: <7cf8fffc-4198-11af-86a8-3db575524e79@oracle.com> Hi Tobias, On 2019-11-06 16:57, Tobias Hartmann wrote: > Hi Claes, > > very nice. While you're at it, could you add brackets to the for-loops/ifs in vectset.cpp:70, > vectset.hpp:89, 98 and fix the whitespacing? No new webrev required. will do! /Claes From zgu at redhat.com Thu Nov 7 14:33:00 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Nov 2019 09:33:00 -0500 Subject: RFR(T) 8233796: Shenandoah is broken after 8233708 Message-ID: <32fa496f-6ad9-5f07-2f4f-ad3cdb538a88@redhat.com> Please review this trivial patch to unbreak Shenandoah build. Bug: https://bugs.openjdk.java.net/browse/JDK-8233796 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233796/webrev.00/ Thanks, -Zhengyu From rkennke at redhat.com Thu Nov 7 14:39:54 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Nov 2019 15:39:54 +0100 Subject: RFR(T) 8233796: Shenandoah is broken after 8233708 In-Reply-To: <32fa496f-6ad9-5f07-2f4f-ad3cdb538a88@redhat.com> References: <32fa496f-6ad9-5f07-2f4f-ad3cdb538a88@redhat.com> Message-ID: <8593ac07-5c43-f8be-489e-3e5e697cb179@redhat.com> Ok. Roman > Please review this trivial patch to unbreak Shenandoah build. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233796 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233796/webrev.00/ > > > Thanks, > > -Zhengyu > From zgu at redhat.com Thu Nov 7 14:55:13 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Nov 2019 09:55:13 -0500 Subject: RFR(XS) 8233337: Shenandoah: Cleanup AArch64 SBSA::load_reference_barrier_not_null() Message-ID: <5de422c4-ea76-81b0-8413-d3e81f60a09d@redhat.com> Please review this cleanup patch suggested by Andrew Haley. Please see [1] for details Bug: https://bugs.openjdk.java.net/browse/JDK-8233337 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233337/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) on AArch64 Linux Thanks, -Zhengyu [1] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010976.html From rkennke at redhat.com Thu Nov 7 15:37:08 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Nov 2019 16:37:08 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8233337: Shenandoah: Cleanup AArch64 SBSA::load_reference_barrier_not_null() In-Reply-To: <5de422c4-ea76-81b0-8413-d3e81f60a09d@redhat.com> References: <5de422c4-ea76-81b0-8413-d3e81f60a09d@redhat.com> Message-ID: Looks good,thanks! Roman > Please review this cleanup patch suggested by Andrew Haley. Please see > [1] for details > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233337 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233337/webrev.00/ > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) > ? on AArch64 Linux > > Thanks, > > -Zhengyu > > > > > [1] > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010976.html > > From zgu at redhat.com Thu Nov 7 19:01:42 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Nov 2019 14:01:42 -0500 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> <0fb9cd70-0a89-8c14-7469-55205c4c3808@redhat.com> Message-ID: <9f4e51fd-dd2c-1f74-e695-51923c75a52a@redhat.com> > > Filed: https://bugs.openjdk.java.net/browse/JDK-8233401 Rebased on top of JDK-8233401 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.02/index.html Thanks, -Zhengyu > > Matter of fact, I would like to hold off this code review, till reactor > is done. > > Thanks, > > -Zhengyu > >> >> *) shenandoahBarrierSetAssembler_x86.cpp, I believe it would be more >> straightforward to save >> branching on local variable "need_load_reference_barrier" by spelling >> out the "disabled" path >> directly (in fact, I think you are almost there in >> shenandoahBarrierSetC1.cpp!): >> >> ?? if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, >> type)) { >> ???? BarrierSetAssembler::load_at(masm, decorators, type, dst, src, >> tmp1, tmp_thread); >> ???? return; >> ?? } >> >> ?? ... code that assumes need_load_reference_barrier = true follows ... >> >> ?? Register result_dst = dst; >> ?? bool use_tmp1_for_dst = false; >> >> *) shenandoahBarrierSetC1.cpp: local variable >> "need_load_reference_barrier" is not needed, there is >> only a single use >> >> *) shenandoahBarrierSetC2.cpp: this block should go all the way up: >> >> ? 557?? if >> (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { >> ? 558???? return load; >> ? 559?? } >> >> *) shenandoahBarrierSet.cpp: this is just "return >> is_reference_type(type)". Saves some inversions. >> >> ?? 78?? if (!is_reference_type(type)) return false; >> ?? 79?? return true; >> >> *) shenandoahBarrierSet.cpp: should be "Should be subset of LRB": >> >> ?? 83?? assert(need_load_reference_barrier(decorators, type), "Why >> ask?"); >> >> *) shenandoahBarrierSet.cpp: seems like this assert is subsumed by the >> previous one? >> >> ??? 84?? assert(is_reference_type(type), "Why we here?"); >> >> From rkennke at redhat.com Thu Nov 7 19:41:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Nov 2019 20:41:00 +0100 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: <9f4e51fd-dd2c-1f74-e695-51923c75a52a@redhat.com> References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> <0fb9cd70-0a89-8c14-7469-55205c4c3808@redhat.com> <9f4e51fd-dd2c-1f74-e695-51923c75a52a@redhat.com> Message-ID: <4b24e6ac-2109-4a7d-83aa-c2427343e22b@redhat.com> That looks good to me. Thanks, Roman >> >> Filed: https://bugs.openjdk.java.net/browse/JDK-8233401 > > Rebased on top of JDK-8233401 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.02/index.html > > Thanks, > > -Zhengyu > > >> >> Matter of fact, I would like to hold off this code review, till >> reactor is done. >> >> Thanks, >> >> -Zhengyu >> >>> >>> *) shenandoahBarrierSetAssembler_x86.cpp, I believe it would be more >>> straightforward to save >>> branching on local variable "need_load_reference_barrier" by spelling >>> out the "disabled" path >>> directly (in fact, I think you are almost there in >>> shenandoahBarrierSetC1.cpp!): >>> >>> ?? if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, >>> type)) { >>> ???? BarrierSetAssembler::load_at(masm, decorators, type, dst, src, >>> tmp1, tmp_thread); >>> ???? return; >>> ?? } >>> >>> ?? ... code that assumes need_load_reference_barrier = true follows ... >>> >>> ?? Register result_dst = dst; >>> ?? bool use_tmp1_for_dst = false; >>> >>> *) shenandoahBarrierSetC1.cpp: local variable >>> "need_load_reference_barrier" is not needed, there is >>> only a single use >>> >>> *) shenandoahBarrierSetC2.cpp: this block should go all the way up: >>> >>> ? 557?? if >>> (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { >>> ? 558???? return load; >>> ? 559?? } >>> >>> *) shenandoahBarrierSet.cpp: this is just "return >>> is_reference_type(type)". Saves some inversions. >>> >>> ?? 78?? if (!is_reference_type(type)) return false; >>> ?? 79?? return true; >>> >>> *) shenandoahBarrierSet.cpp: should be "Should be subset of LRB": >>> >>> ?? 83?? assert(need_load_reference_barrier(decorators, type), "Why >>> ask?"); >>> >>> *) shenandoahBarrierSet.cpp: seems like this assert is subsumed by >>> the previous one? >>> >>> ??? 84?? assert(is_reference_type(type), "Why we here?"); >>> >>> From zgu at redhat.com Thu Nov 7 19:42:27 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Nov 2019 14:42:27 -0500 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet In-Reply-To: <4b24e6ac-2109-4a7d-83aa-c2427343e22b@redhat.com> References: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> <4ed90469-8689-b49d-69f1-98f644e9edd0@redhat.com> <0fb9cd70-0a89-8c14-7469-55205c4c3808@redhat.com> <9f4e51fd-dd2c-1f74-e695-51923c75a52a@redhat.com> <4b24e6ac-2109-4a7d-83aa-c2427343e22b@redhat.com> Message-ID: <31415213-3464-619a-0741-ca14f7b9cbcf@redhat.com> Thanks for the review, Roman -Zhengyu On 11/7/19 2:41 PM, Roman Kennke wrote: > That looks good to me. > > Thanks, > Roman > >>> >>> Filed: https://bugs.openjdk.java.net/browse/JDK-8233401 >> >> Rebased on top of JDK-8233401 >> >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.02/index.html >> >> Thanks, >> >> -Zhengyu >> >> >>> >>> Matter of fact, I would like to hold off this code review, till >>> reactor is done. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>>> >>>> *) shenandoahBarrierSetAssembler_x86.cpp, I believe it would be more >>>> straightforward to save >>>> branching on local variable "need_load_reference_barrier" by spelling >>>> out the "disabled" path >>>> directly (in fact, I think you are almost there in >>>> shenandoahBarrierSetC1.cpp!): >>>> >>>> ?? if (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, >>>> type)) { >>>> ???? BarrierSetAssembler::load_at(masm, decorators, type, dst, src, >>>> tmp1, tmp_thread); >>>> ???? return; >>>> ?? } >>>> >>>> ?? ... code that assumes need_load_reference_barrier = true follows ... >>>> >>>> ?? Register result_dst = dst; >>>> ?? bool use_tmp1_for_dst = false; >>>> >>>> *) shenandoahBarrierSetC1.cpp: local variable >>>> "need_load_reference_barrier" is not needed, there is >>>> only a single use >>>> >>>> *) shenandoahBarrierSetC2.cpp: this block should go all the way up: >>>> >>>> ? 557?? if >>>> (!ShenandoahBarrierSet::need_load_reference_barrier(decorators, type)) { >>>> ? 558???? return load; >>>> ? 559?? } >>>> >>>> *) shenandoahBarrierSet.cpp: this is just "return >>>> is_reference_type(type)". Saves some inversions. >>>> >>>> ?? 78?? if (!is_reference_type(type)) return false; >>>> ?? 79?? return true; >>>> >>>> *) shenandoahBarrierSet.cpp: should be "Should be subset of LRB": >>>> >>>> ?? 83?? assert(need_load_reference_barrier(decorators, type), "Why >>>> ask?"); >>>> >>>> *) shenandoahBarrierSet.cpp: seems like this assert is subsumed by >>>> the previous one? >>>> >>>> ??? 84?? assert(is_reference_type(type), "Why we here?"); >>>> >>>> > From amirhadadi at hotmail.com Fri Nov 8 12:12:13 2019 From: amirhadadi at hotmail.com (Amir Hadadi) Date: Fri, 8 Nov 2019 12:12:13 +0000 Subject: Shenandoah thread count ergonomics not container aware due to JDK-8225229 Message-ID: Hi, When using Shenandoah in a docker container on JDK 13, the number of CPUs allocated to the container is ignored. Seems like https://bugs.openjdk.java.net/browse/JDK-8225229 made Shenandoah use os::processor_count() which is not container aware. From zgu at redhat.com Fri Nov 8 14:57:47 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 8 Nov 2019 09:57:47 -0500 Subject: Shenandoah thread count ergonomics not container aware due to JDK-8225229 In-Reply-To: References: Message-ID: Hi Amir, Thanks for reporting. I filed JDK-8233850 [1] to fix this. Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8233850 On 11/8/19 7:12 AM, Amir Hadadi wrote: > Hi, > When using Shenandoah in a docker container on JDK 13, the number of CPUs allocated to the container is ignored. > Seems like https://bugs.openjdk.java.net/browse/JDK-8225229 made Shenandoah use os::processor_count() which is not container aware. > From zgu at redhat.com Fri Nov 8 16:38:44 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 8 Nov 2019 11:38:44 -0500 Subject: RFR 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware Message-ID: <2b9e8e24-d4bf-9e60-aa59-1b0daf98091a@redhat.com> Please review this small patch that uses container-aware os::initial_active_processor_count() API for calculating worker thread count ergonomics. Bug: https://bugs.openjdk.java.net/browse/JDK-8233850 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233850/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From rkennke at redhat.com Fri Nov 8 16:40:15 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Nov 2019 17:40:15 +0100 Subject: RFR 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware In-Reply-To: <2b9e8e24-d4bf-9e60-aa59-1b0daf98091a@redhat.com> References: <2b9e8e24-d4bf-9e60-aa59-1b0daf98091a@redhat.com> Message-ID: <46de5f98-5bab-73e9-c0de-f66f819bd2b3@redhat.com> Looks good to me. Thanks! Roman > Please review this small patch that uses container-aware > os::initial_active_processor_count() API for calculating worker thread > count ergonomics. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233850 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233850/webrev.00/ > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) > > > Thanks, > > -Zhengyu > From rkennke at redhat.com Mon Nov 11 14:38:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Nov 2019 15:38:56 +0100 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> <8ee880f9-bc96-4349-c13f-b433fa746ad8@redhat.com> Message-ID: Hi Alexander, Have you been able to make any progress with this issue? I'm still digging. Even just having more hs_err files might help. Getting a failure from a fastdebug build would be better, but I am not sure this would even reproduce with fastdebug ? Thanks, Roman > The object alignment part is most probably not the cause of this. The error > log I sent you is from a QA machine which is smaller, so I reduce -Xmx > there while keeping the rest of the options unchanged (including object > alignment). In production (where the crash originally happened), the heap > is set to 62g. > > Regarding the fastdebug build, this will take a bit longer. Fastdebug build > is so slow that the application can't even start in time to not be killed > by the load balancer healthchecks:). I'll repat the experiment tomorrow. > > On Mon, 4 Nov 2019 at 18:33, Aleksey Shipilev wrote: > >> On 11/4/19 4:44 PM, Alexander Yakushev wrote: >>> Hello again! After some time, I finally managed to reproduce the crash >> in a non-production >>> environment with +ShenandoahVerify. I attach the hs_err file. >> >> Thanks. I notice that you are running in the unusual configuration: >> -Xmx12g -Xms12g -XX:ObjectAlignmentInBytes=16 >> >> Alignment to 16 bytes is not needed for the heap this small, and it just >> wastes memory. >> >> We are trying to see if that could be the source of bugs too... >> >>> This was reproduced with a regular shenandoah-jdk8 build. Meanwhile, >> I've built the application with >>> fastdebug build and will try with that too if necessary. >> >> Yes, that would be handy. The current hs_err does not yield interesting >> failure, it seems to be NULL >> dereference somewhere ObjectMonitor code -- which may or may not be the GC >> fault. Need to meditate >> on this a little bit... >> >> -- >> Thanks, >> -Aleksey >> >> From rkennke at redhat.com Mon Nov 11 14:56:31 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Nov 2019 15:56:31 +0100 Subject: RFR: (sh/8): [backport] 8226757: Shenandoah: Make traversal and passive modes explicit Message-ID: This backports the machinery that introduces ShenandoahGCMode, in preparation for the Traversal GC backport. Contrary to the corresponding 11+ changes, this does not include the traversal mode. However, I will push this change together with the big traversal GC backport. Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8226757-jdk8/webrev.00/ Testing: hotspot_gc_shenandoah Can I please get a review? Roman From rkennke at redhat.com Mon Nov 11 15:05:42 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Nov 2019 16:05:42 +0100 Subject: RFR: (sh/8): Backport per-region seqnum tracking Message-ID: <52609c01-1e40-4699-7a7c-3b49aa44bfc0@redhat.com> This backports the per-region seqnum tracking, which is used by the traversal GC. It doesn't come with a bug-ID because it pre-dates Shenandoah upstreaming. I'd push it together with the Traversal GC backport. Webrev: http://cr.openjdk.java.net/~rkennke/shjdk8-seqnum/webrev.01/ Testing: hotspot_gc_shenandoah Ok? Roman From rkennke at redhat.com Mon Nov 11 15:21:45 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Nov 2019 16:21:45 +0100 Subject: RFR (sh/8): Backport Traversal GC Message-ID: <1c035bb9-d387-5f87-159e-76b770184b4e@redhat.com> This backports the Traversal GC mode from sh/jdk11. Some notable changes had to be made: - The GC interface is radically different between jdk8 and jdk11. I hooked up the new barriers to mostly-existing machinery for pre- or post-barriers for G1. This covers everything that we need for traversal GC. - The patch introduces ShenandoahKeepAliveBarrier, and thusly changes many uses of ShenandoahSATBBarrier to that. - We need an extra scan-all-roots-pass in init-traversal when we are doing class-unloading, because we need to pre-evac-and-update all weak roots. This is required because we don't have native LRB in 8. Testing: hotspot_gc_shenandoah (x86_64, x86_32, aarch64 all without PCH, all with fastdebug and release builds), specjvm and specjbb with fastdebug/+ShVerify and release build Webrev: http://cr.openjdk.java.net/~rkennke/shjdk8-traversal/webrev.00/ Can I please get a review? Roman From zgu at redhat.com Tue Nov 12 13:03:51 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 Nov 2019 08:03:51 -0500 Subject: RFR: (sh/8): Backport per-region seqnum tracking In-Reply-To: <52609c01-1e40-4699-7a7c-3b49aa44bfc0@redhat.com> References: <52609c01-1e40-4699-7a7c-3b49aa44bfc0@redhat.com> Message-ID: <6bc16b54-b61f-3ae1-4d6f-167111ab8ec0@redhat.com> Good to me. -Zhengyu On 11/11/19 10:05 AM, Roman Kennke wrote: > This backports the per-region seqnum tracking, which is used by the > traversal GC. It doesn't come with a bug-ID because it pre-dates > Shenandoah upstreaming. I'd push it together with the Traversal GC backport. > > Webrev: > http://cr.openjdk.java.net/~rkennke/shjdk8-seqnum/webrev.01/ > > Testing: hotspot_gc_shenandoah > > Ok? > > Roman > From zgu at redhat.com Tue Nov 12 13:05:25 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 Nov 2019 08:05:25 -0500 Subject: RFR: (sh/8): [backport] 8226757: Shenandoah: Make traversal and passive modes explicit In-Reply-To: References: Message-ID: <8c6b7cf3-4d6c-faf3-b3d7-0a51ceead766@redhat.com> Ok. -Zhengyu On 11/11/19 9:56 AM, Roman Kennke wrote: > This backports the machinery that introduces ShenandoahGCMode, in > preparation for the Traversal GC backport. Contrary to the corresponding > 11+ changes, this does not include the traversal mode. However, I will > push this change together with the big traversal GC backport. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8226757-jdk8/webrev.00/ > > Testing: hotspot_gc_shenandoah > > Can I please get a review? > > Roman > From zgu at redhat.com Tue Nov 12 13:13:47 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 Nov 2019 08:13:47 -0500 Subject: RFR (sh/8): Backport Traversal GC In-Reply-To: <1c035bb9-d387-5f87-159e-76b770184b4e@redhat.com> References: <1c035bb9-d387-5f87-159e-76b770184b4e@redhat.com> Message-ID: <420d6695-87c9-8b58-c3d6-f84d590c69ff@redhat.com> Okay, Thanks. -Zhengyu On 11/11/19 10:21 AM, Roman Kennke wrote: > This backports the Traversal GC mode from sh/jdk11. > > Some notable changes had to be made: > - The GC interface is radically different between jdk8 and jdk11. I > hooked up the new barriers to mostly-existing machinery for pre- or > post-barriers for G1. This covers everything that we need for traversal GC. > - The patch introduces ShenandoahKeepAliveBarrier, and thusly changes > many uses of ShenandoahSATBBarrier to that. > - We need an extra scan-all-roots-pass in init-traversal when we are > doing class-unloading, because we need to pre-evac-and-update all weak > roots. This is required because we don't have native LRB in 8. > > Testing: hotspot_gc_shenandoah (x86_64, x86_32, aarch64 all without PCH, > all with fastdebug and release builds), specjvm and specjbb with > fastdebug/+ShVerify and release build > > Webrev: > http://cr.openjdk.java.net/~rkennke/shjdk8-traversal/webrev.00/ > > Can I please get a review? > > Roman > From rkennke at redhat.com Tue Nov 12 14:58:48 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 12 Nov 2019 14:58:48 +0000 Subject: hg: shenandoah/jdk8/hotspot: 3 new changesets Message-ID: <201911121458.xACEwm12022536@aojmv0008.oracle.com> Changeset: a8252208b533 Author: rkennke Date: 2019-11-08 10:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a8252208b533 [backport] 8226757: Shenandoah: Make traversal and passive modes explicit ! 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/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/jni/TestJNIGlobalRefs.sh ! test/gc/shenandoah/jni/TestPinnedGarbage.sh ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestHumongousMoves.java ! test/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: b4a4b8691f19 Author: rkennke Date: 2019-11-11 16:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b4a4b8691f19 Backport per-region seqnum tracking ! 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/shenandoahVerifier.cpp Changeset: 5935510ea5e7 Author: rkennke Date: 2019-11-11 16:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5935510ea5e7 Backport Traversal GC ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.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/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/shenandoahHeapRegionCounters.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.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_interface/gcCause.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vm_operations.hpp ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRefprocSanity.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/TestWrongArrayMember.java ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java From rkennke at redhat.com Tue Nov 12 15:35:09 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 Nov 2019 16:35:09 +0100 Subject: RFR (sh/11): Remove to wrong handlings of Shenandoah LRB in escape analysis Message-ID: There are two cases of wrong handling of LRB in escape.cpp. Those are not present in any way in jdk/jdk and may cause bugs. Testing: hotspot_gc_shenandoah (fastdebug/release) some specjvm sanity tests http://cr.openjdk.java.net/~rkennke/shjdk11-fixea/webrev.00/ Can I please get a review? Thanks, Roman From rkennke at redhat.com Tue Nov 12 19:43:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 Nov 2019 20:43:52 +0100 Subject: RFR (sh/8): Remove some obsolete Shenandoah code from C2 Message-ID: This removes a block of code that looks like it's not necessary anymore. According to hg annotate, it appears to be from our first import into this tree. It's most likely related to our previous barrier scheme. I removed the code and run a bunch of tests: Tests: hotspot_gc_shenandoah (fastdebug/release), specjvm, specjbb with no ill effects. Webrev: http://cr.openjdk.java.net/~rkennke/shjdk8-remove-cruft1/webrev.00/ Can I please get a review? Thanks, Roman From rkennke at redhat.com Tue Nov 12 20:50:46 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 Nov 2019 21:50:46 +0100 Subject: RFR (sh/8): Revert obsolete shared-code changes in runtime synchronizer code Message-ID: This reverts shared-code changes in synchronizer.cpp and biasedLocking.cpp in shenandoah/jdk8. Those are no longer needed because of LRB. Functionally it should be equivalent, but better to keep the upstream versions and trim down the Shenandoah diff. Webrev: http://cr.openjdk.java.net/~rkennke/shjdk8-remove-cruft2/webrev.00/ Testing: hotspot_gc_shenandoah Can I please get a review? Thanks, Roman From zgu at redhat.com Tue Nov 12 21:09:55 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 Nov 2019 16:09:55 -0500 Subject: RFR (sh/8): Revert obsolete shared-code changes in runtime synchronizer code In-Reply-To: References: Message-ID: Okay Thanks. -Zhengyu On 11/12/19 3:50 PM, Roman Kennke wrote: > This reverts shared-code changes in synchronizer.cpp and > biasedLocking.cpp in shenandoah/jdk8. Those are no longer needed because > of LRB. Functionally it should be equivalent, but better to keep the > upstream versions and trim down the Shenandoah diff. > > Webrev: > http://cr.openjdk.java.net/~rkennke/shjdk8-remove-cruft2/webrev.00/ > > Testing: hotspot_gc_shenandoah > > Can I please get a review? > > Thanks, > Roman > From rkennke at redhat.com Tue Nov 12 21:20:26 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 12 Nov 2019 21:20:26 +0000 Subject: hg: shenandoah/jdk8/hotspot: Revert obsolete shared-code changes in runtime synchronizer code Message-ID: <201911122120.xACLKQo9025430@aojmv0008.oracle.com> Changeset: bd480a95ed11 Author: rkennke Date: 2019-11-12 22:22 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bd480a95ed11 Revert obsolete shared-code changes in runtime synchronizer code ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/synchronizer.cpp From rwestrel at redhat.com Wed Nov 13 09:24:22 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 13 Nov 2019 10:24:22 +0100 Subject: RFR (sh/11): Remove to wrong handlings of Shenandoah LRB in escape analysis In-Reply-To: References: Message-ID: <877e44dt89.fsf@redhat.com> > http://cr.openjdk.java.net/~rkennke/shjdk11-fixea/webrev.00/ Good. Roland. From rwestrel at redhat.com Wed Nov 13 09:24:51 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 13 Nov 2019 10:24:51 +0100 Subject: RFR (sh/8): Remove some obsolete Shenandoah code from C2 In-Reply-To: References: Message-ID: <874kz8dt7g.fsf@redhat.com> > http://cr.openjdk.java.net/~rkennke/shjdk8-remove-cruft1/webrev.00/ Ok. Roland. From genus.alexey at gmail.com Wed Nov 13 09:51:26 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Wed, 13 Nov 2019 12:51:26 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 Message-ID: Hello, Shenandoah devs. I updated jdk8 from 191-b12 to 232-b09 and started to get spurious freezes of my application during startup which occur pretty consistently. Digging into gave me impression that is something wrong with java itself. Having tried to use fastdebug build I started to get these hs_err.logs: https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd and another possible outcome is same as earlier - hung jvm which heavily consumes CPU in GC threads with a stacktrace like that (got it with perf): 32.32% libjvm.so [.] ShenandoahAsserts::assert_correct 16.16% libjvm.so [.] ShenandoahBarrierSet::write_barrier 10.10% libjvm.so [.] JvmtiTagMap::do_weak_oops 8.43% libjvm.so [.] ShenandoahForwardedIsAliveClosure::do_object_b 8.25% libjvm.so [.] ShenandoahEvacuateUpdateRootsClosure::do_oop_work 6.71% libjvm.so [.] ShenandoahHeap::in_collection_set 6.16% libjvm.so [.] ShenandoahHeap::is_in 5.53% libjvm.so [.] Metaspace::contains 2.70% libjvm.so [.] ShenandoahHeap::heap 2.43% libjvm.so [.] ShenandoahHeap::kind 0.76% libjvm.so [.] ShenandoahHeap::heap_no_check 0.24% [kernel] [k] trigger_load_balance 0.14% [kernel] [k] system_call_fastpath Aleksey Shipilev suggested running on latest shenandoah-backport. I did it and it gave me another error in 100% cases (probably unrelated to original error). The log is here https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b Moving back to 1.8.0.192 helps, but maybe we can find the error here. Unfortunately I don't haven a minimal reproducible example, but I'm open to any suggestions on how to make it. Do you have any thoughts about how to fix this? Alexey From rkennke at redhat.com Wed Nov 13 11:01:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 12:01:13 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: Message-ID: <23dae8f1-cfd6-1780-df72-62696382ce6b@redhat.com> Hi Alexey, first of all, thank you for reporting and digging so deep! See comments inline: > Hello, Shenandoah devs. > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious freezes > of my application during startup which occur pretty consistently. Digging > into gave me impression that is something wrong with java itself. Having > tried to use fastdebug build I started to get these hs_err.logs: > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 This is a C2 problem, probably caused by Shenandoah's barriers. Since we changed to a wholly different barrier model, it's not clear whether or not this problem persists. Probably not. We need to see if it happens again with current shenandoah/jdk8. > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd This looks like an issue related to JVMTI, and may or may not be Shenandoah specific. We fixed an issue with JVMTI root scanning, but this stacktrace doesn't look obviously related. We should look into it. > and another possible outcome is same as earlier - hung jvm which heavily > consumes CPU in GC threads with a stacktrace like that (got it with perf): > 32.32% libjvm.so [.] ShenandoahAsserts::assert_correct > 16.16% libjvm.so [.] ShenandoahBarrierSet::write_barrier > 10.10% libjvm.so [.] JvmtiTagMap::do_weak_oops > 8.43% libjvm.so [.] ShenandoahForwardedIsAliveClosure::do_object_b > 8.25% libjvm.so [.] > ShenandoahEvacuateUpdateRootsClosure::do_oop_work > 6.71% libjvm.so [.] ShenandoahHeap::in_collection_set > 6.16% libjvm.so [.] ShenandoahHeap::is_in > 5.53% libjvm.so [.] Metaspace::contains > 2.70% libjvm.so [.] ShenandoahHeap::heap > 2.43% libjvm.so [.] ShenandoahHeap::kind > 0.76% libjvm.so [.] ShenandoahHeap::heap_no_check > 0.24% [kernel] [k] trigger_load_balance > 0.14% [kernel] [k] system_call_fastpath This is most likely fixed already, being the JVMTI root scanning issue. > Aleksey Shipilev suggested running on latest shenandoah-backport. I did it > and it gave me another error in 100% cases (probably unrelated to original > error). The log is here > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > It means that the code buffer for initial code is too small. I am not sure why this would happen for you, but not for me. However, we should try this: https://paste.fedoraproject.org/paste/3Tpm34drmQDqRYUExq~9SA If you are able to build a JVM with this patch you could try it out directly, otherwise I'll commit that for testing purposes and you could pick up one of our nightlies as soon as it appears? It's a little bit tricky because I can only blindly increase the code_size1 until we have enough. It may take a few rounds of trying... Roman From rkennke at redhat.com Wed Nov 13 11:04:32 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 12:04:32 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: Message-ID: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> I just realized that in your latest test you used a Zero VM. This is most likely not what you wanted ;-) Please try: Release build: https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz Fastdebug build: https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz Thanks, Roman > Hello, Shenandoah devs. > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious freezes > of my application during startup which occur pretty consistently. Digging > into gave me impression that is something wrong with java itself. Having > tried to use fastdebug build I started to get these hs_err.logs: > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd > and another possible outcome is same as earlier - hung jvm which heavily > consumes CPU in GC threads with a stacktrace like that (got it with perf): > 32.32% libjvm.so [.] ShenandoahAsserts::assert_correct > 16.16% libjvm.so [.] ShenandoahBarrierSet::write_barrier > 10.10% libjvm.so [.] JvmtiTagMap::do_weak_oops > 8.43% libjvm.so [.] ShenandoahForwardedIsAliveClosure::do_object_b > 8.25% libjvm.so [.] > ShenandoahEvacuateUpdateRootsClosure::do_oop_work > 6.71% libjvm.so [.] ShenandoahHeap::in_collection_set > 6.16% libjvm.so [.] ShenandoahHeap::is_in > 5.53% libjvm.so [.] Metaspace::contains > 2.70% libjvm.so [.] ShenandoahHeap::heap > 2.43% libjvm.so [.] ShenandoahHeap::kind > 0.76% libjvm.so [.] ShenandoahHeap::heap_no_check > 0.24% [kernel] [k] trigger_load_balance > 0.14% [kernel] [k] system_call_fastpath > > Aleksey Shipilev suggested running on latest shenandoah-backport. I did it > and it gave me another error in 100% cases (probably unrelated to original > error). The log is here > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > > Moving back to 1.8.0.192 helps, but maybe we can find the error here. > Unfortunately I don't haven a minimal reproducible example, but I'm open to > any suggestions on how to make it. > Do you have any thoughts about how to fix this? > > Alexey > From rkennke at redhat.com Wed Nov 13 11:08:02 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 13 Nov 2019 11:08:02 +0000 Subject: hg: shenandoah/jdk11: Remove to wrong handlings of Shenandoah LRB in escape analysis Message-ID: <201911131108.xADB83dA014114@aojmv0008.oracle.com> Changeset: 2f527cba09e8 Author: rkennke Date: 2019-11-12 16:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/2f527cba09e8 Remove to wrong handlings of Shenandoah LRB in escape analysis ! src/hotspot/share/opto/escape.cpp From rkennke at redhat.com Wed Nov 13 11:25:09 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 13 Nov 2019 11:25:09 +0000 Subject: hg: shenandoah/jdk8/hotspot: Remove some obsolete Shenandoah code from C2 Message-ID: <201911131125.xADBPA5k023715@aojmv0008.oracle.com> Changeset: 282516993f97 Author: rkennke Date: 2019-11-13 12:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/282516993f97 Remove some obsolete Shenandoah code from C2 ! src/share/vm/opto/addnode.cpp From rkennke at redhat.com Wed Nov 13 12:55:46 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 13:55:46 +0100 Subject: [11] RFR/RFC: Pick up 11.0.6+2 to sh/jdk11 Message-ID: 11u updates project had tagged the 11.0.6+2, which includes a bunch of outstanding changes in 11u project. Let's pick those up. The merge was trivial. Changeset list: http://cr.openjdk.java.net/~rkennke/sh-jdk11-11.0.6%2b02/changesets.txt Testing: hotspot_gc_shenandoah {fastdebug,release} I'd push the tag shenandoah-jdk-11.0.6+2 together with this merge. Ok? Roman From genus.alexey at gmail.com Wed Nov 13 12:58:31 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Wed, 13 Nov 2019 15:58:31 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> Message-ID: Roman, indeed I didn't want to use Zero VM - my fault must be misclick when I downloaded the build. Just downloaded latest snapshot and tried it out. 1. Just to be clear I use x86_64, not aarch64. Builds from shipilev.net erroneously say they are aarch64 even for x86_64 builds. 2. Freezes indeed are gone. That's already good news. 3. Error with possible deadlock (from https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still exists 4. Original C2 issue is gone, nut new one appeared, please see https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b Alexey On Wed, 13 Nov 2019 at 14:06, Roman Kennke wrote: > I just realized that in your latest test you used a Zero VM. This is > most likely not what you wanted ;-) > > Please try: > > Release build: > > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz > > Fastdebug build: > > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz > > Thanks, > Roman > > > > Hello, Shenandoah devs. > > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious > freezes > > of my application during startup which occur pretty consistently. Digging > > into gave me impression that is something wrong with java itself. Having > > tried to use fastdebug build I started to get these hs_err.logs: > > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 > > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd > > and another possible outcome is same as earlier - hung jvm which heavily > > consumes CPU in GC threads with a stacktrace like that (got it with > perf): > > 32.32% libjvm.so [.] ShenandoahAsserts::assert_correct > > 16.16% libjvm.so [.] ShenandoahBarrierSet::write_barrier > > 10.10% libjvm.so [.] JvmtiTagMap::do_weak_oops > > 8.43% libjvm.so [.] ShenandoahForwardedIsAliveClosure::do_object_b > > 8.25% libjvm.so [.] > > ShenandoahEvacuateUpdateRootsClosure::do_oop_work > > 6.71% libjvm.so [.] ShenandoahHeap::in_collection_set > > 6.16% libjvm.so [.] ShenandoahHeap::is_in > > 5.53% libjvm.so [.] Metaspace::contains > > 2.70% libjvm.so [.] ShenandoahHeap::heap > > 2.43% libjvm.so [.] ShenandoahHeap::kind > > 0.76% libjvm.so [.] ShenandoahHeap::heap_no_check > > 0.24% [kernel] [k] trigger_load_balance > > 0.14% [kernel] [k] system_call_fastpath > > > > Aleksey Shipilev suggested running on latest shenandoah-backport. I did > it > > and it gave me another error in 100% cases (probably unrelated to > original > > error). The log is here > > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > > > > Moving back to 1.8.0.192 helps, but maybe we can find the error here. > > Unfortunately I don't haven a minimal reproducible example, but I'm open > to > > any suggestions on how to make it. > > Do you have any thoughts about how to fix this? > > > > Alexey > > > > From rkennke at redhat.com Wed Nov 13 13:07:28 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 14:07:28 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> Message-ID: Hi Alexey, > indeed I didn't? want to use Zero VM - my fault must be misclick when I > downloaded the build. > Just downloaded latest snapshot and tried it out. > 1. Just to be clear I use x86_64, not aarch64. Builds from shipilev.net > erroneously say they are aarch64 even for x86_64 > builds. Oh, wow. That's bad. We shall fix that then. And I was wondering why we have this surge of aarch64 early adopters. > 2. Freezes indeed are gone. That's already good news. Great! > 3. Error with possible deadlock (from > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still > exists I will look into this right now. > 4. Original C2 issue is gone, nut new one appeared, please > see?https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b We might need to see the corresponding replay file (with the same PID as the hs_err file), and ideally the class files/JARs involved in this. Thanks, Roman > Alexey > > On Wed, 13 Nov 2019 at 14:06, Roman Kennke > wrote: > > I just realized that in your latest test you used a Zero VM. This is > most likely not what you wanted ;-) > > Please try: > > Release build: > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz > > Fastdebug build: > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz > > Thanks, > Roman > > > > Hello, Shenandoah devs. > > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious > freezes > > of my application during startup which occur pretty consistently. > Digging > > into gave me impression that is something wrong with java itself. > Having > > tried to use fastdebug build I started to get these hs_err.logs: > > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 > > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd > > and another possible outcome is same as earlier - hung jvm which > heavily > > consumes CPU in GC threads with a stacktrace like that (got it > with perf): > > 32.32%? libjvm.so? ? ?[.] ShenandoahAsserts::assert_correct > > 16.16%? libjvm.so? ? ?[.] ShenandoahBarrierSet::write_barrier > > 10.10%? libjvm.so? ? ?[.] JvmtiTagMap::do_weak_oops > > 8.43%? libjvm.so? ? ? [.] > ShenandoahForwardedIsAliveClosure::do_object_b > > 8.25%? libjvm.so? ? ? [.] > > ShenandoahEvacuateUpdateRootsClosure::do_oop_work > > 6.71%? libjvm.so? ? ? [.] ShenandoahHeap::in_collection_set > > 6.16%? libjvm.so? ? ? [.] ShenandoahHeap::is_in > > 5.53%? libjvm.so? ? ? [.] Metaspace::contains > > 2.70%? libjvm.so? ? ? [.] ShenandoahHeap::heap > > 2.43%? libjvm.so? ? ? [.] ShenandoahHeap::kind > > 0.76%? libjvm.so? ? ? [.] ShenandoahHeap::heap_no_check > > 0.24%? [kernel]? ? ? ?[k] trigger_load_balance > > 0.14%? [kernel]? ? ? ?[k] system_call_fastpath > > > > Aleksey Shipilev suggested running on latest shenandoah-backport. > I did it > > and it gave me another error in 100% cases (probably unrelated to > original > > error). The log is here > > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > > > > Moving back to 1.8.0.192 helps, but maybe we can find the error here. > > Unfortunately I don't haven a minimal reproducible example, but > I'm open to > > any suggestions on how to make it. > > Do you have any thoughts about how to fix this? > > > > Alexey > > > From genus.alexey at gmail.com Wed Nov 13 13:58:38 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Wed, 13 Nov 2019 16:58:38 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> Message-ID: Roman, I uploaded replay file for that very run https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 Attached file is the class-file which caused error. This is an unusual class which was generated by one-nio in this method . On Wed, 13 Nov 2019 at 16:08, Roman Kennke wrote: > Hi Alexey, > > > indeed I didn't want to use Zero VM - my fault must be misclick when I > > downloaded the build. > > Just downloaded latest snapshot and tried it out. > > 1. Just to be clear I use x86_64, not aarch64. Builds from shipilev.net > > erroneously say they are aarch64 even for x86_64 > > builds. > > Oh, wow. That's bad. We shall fix that then. And I was wondering why we > have this surge of aarch64 early adopters. > > > 2. Freezes indeed are gone. That's already good news. > > Great! > > > 3. Error with possible deadlock (from > > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still > > exists > > I will look into this right now. > > > 4. Original C2 issue is gone, nut new one appeared, please > > see https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b > > We might need to see the corresponding replay file (with the same PID as > the hs_err file), and ideally the class files/JARs involved in this. > > Thanks, > Roman > > > Alexey > > > > On Wed, 13 Nov 2019 at 14:06, Roman Kennke > > wrote: > > > > I just realized that in your latest test you used a Zero VM. This is > > most likely not what you wanted ;-) > > > > Please try: > > > > Release build: > > > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz > > > > Fastdebug build: > > > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz > > > > Thanks, > > Roman > > > > > > > Hello, Shenandoah devs. > > > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious > > freezes > > > of my application during startup which occur pretty consistently. > > Digging > > > into gave me impression that is something wrong with java itself. > > Having > > > tried to use fastdebug build I started to get these hs_err.logs: > > > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 > > > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd > > > and another possible outcome is same as earlier - hung jvm which > > heavily > > > consumes CPU in GC threads with a stacktrace like that (got it > > with perf): > > > 32.32% libjvm.so [.] ShenandoahAsserts::assert_correct > > > 16.16% libjvm.so [.] ShenandoahBarrierSet::write_barrier > > > 10.10% libjvm.so [.] JvmtiTagMap::do_weak_oops > > > 8.43% libjvm.so [.] > > ShenandoahForwardedIsAliveClosure::do_object_b > > > 8.25% libjvm.so [.] > > > ShenandoahEvacuateUpdateRootsClosure::do_oop_work > > > 6.71% libjvm.so [.] ShenandoahHeap::in_collection_set > > > 6.16% libjvm.so [.] ShenandoahHeap::is_in > > > 5.53% libjvm.so [.] Metaspace::contains > > > 2.70% libjvm.so [.] ShenandoahHeap::heap > > > 2.43% libjvm.so [.] ShenandoahHeap::kind > > > 0.76% libjvm.so [.] ShenandoahHeap::heap_no_check > > > 0.24% [kernel] [k] trigger_load_balance > > > 0.14% [kernel] [k] system_call_fastpath > > > > > > Aleksey Shipilev suggested running on latest shenandoah-backport. > > I did it > > > and it gave me another error in 100% cases (probably unrelated to > > original > > > error). The log is here > > > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > > > > > > Moving back to 1.8.0.192 helps, but maybe we can find the error > here. > > > Unfortunately I don't haven a minimal reproducible example, but > > I'm open to > > > any suggestions on how to make it. > > > Do you have any thoughts about how to fix this? > > > > > > Alexey > > > > > > > From rkennke at redhat.com Wed Nov 13 15:30:12 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 16:30:12 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> Message-ID: Hi Alexey, As far as I can currently tell, the "possible deadlock" problem is not Shenandoah related, but would also happen with G1. I filed: https://bugs.openjdk.java.net/browse/JDK-8234096 Thanks, Roman > Roman, > indeed I didn't? want to use Zero VM - my fault must be misclick when I > downloaded the build. > Just downloaded latest snapshot and tried it out. > 1. Just to be clear I use x86_64, not aarch64. Builds from shipilev.net > erroneously say they are aarch64 even for x86_64 > builds. > 2. Freezes indeed are gone. That's already good news. > 3. Error with possible deadlock (from > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still > exists > 4. Original C2 issue is gone, nut new one appeared, please > see?https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b > > > Alexey > > On Wed, 13 Nov 2019 at 14:06, Roman Kennke > wrote: > > I just realized that in your latest test you used a Zero VM. This is > most likely not what you wanted ;-) > > Please try: > > Release build: > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz > > Fastdebug build: > https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz > > Thanks, > Roman > > > > Hello, Shenandoah devs. > > I updated jdk8 from 191-b12 to 232-b09 and started to get spurious > freezes > > of my application during startup which occur pretty consistently. > Digging > > into gave me impression that is something wrong with java itself. > Having > > tried to use fastdebug build I started to get these hs_err.logs: > > https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 > > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd > > and another possible outcome is same as earlier - hung jvm which > heavily > > consumes CPU in GC threads with a stacktrace like that (got it > with perf): > > 32.32%? libjvm.so? ? ?[.] ShenandoahAsserts::assert_correct > > 16.16%? libjvm.so? ? ?[.] ShenandoahBarrierSet::write_barrier > > 10.10%? libjvm.so? ? ?[.] JvmtiTagMap::do_weak_oops > > 8.43%? libjvm.so? ? ? [.] > ShenandoahForwardedIsAliveClosure::do_object_b > > 8.25%? libjvm.so? ? ? [.] > > ShenandoahEvacuateUpdateRootsClosure::do_oop_work > > 6.71%? libjvm.so? ? ? [.] ShenandoahHeap::in_collection_set > > 6.16%? libjvm.so? ? ? [.] ShenandoahHeap::is_in > > 5.53%? libjvm.so? ? ? [.] Metaspace::contains > > 2.70%? libjvm.so? ? ? [.] ShenandoahHeap::heap > > 2.43%? libjvm.so? ? ? [.] ShenandoahHeap::kind > > 0.76%? libjvm.so? ? ? [.] ShenandoahHeap::heap_no_check > > 0.24%? [kernel]? ? ? ?[k] trigger_load_balance > > 0.14%? [kernel]? ? ? ?[k] system_call_fastpath > > > > Aleksey Shipilev suggested running on latest shenandoah-backport. > I did it > > and it gave me another error in 100% cases (probably unrelated to > original > > error). The log is here > > https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > > > > Moving back to 1.8.0.192 helps, but maybe we can find the error here. > > Unfortunately I don't haven a minimal reproducible example, but > I'm open to > > any suggestions on how to make it. > > Do you have any thoughts about how to fix this? > > > > Alexey > > > From rkennke at redhat.com Wed Nov 13 17:40:37 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 18:40:37 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> Message-ID: <97deed18-12f2-263c-73ec-d80e93f3a8c9@redhat.com> In the meantime, you might want to try again with a recent release build. Thanks, Roman > Roman, > I uploaded replay file for that very > run?https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > Attached file is the class-file which caused error. This is an unusual > class which was generated by one-nio > ?in this method > . > > > On Wed, 13 Nov 2019 at 16:08, Roman Kennke > wrote: > > Hi Alexey, > > > indeed I didn't? want to use Zero VM - my fault must be misclick > when I > > downloaded the build. > > Just downloaded latest snapshot and tried it out. > > 1. Just to be clear I use x86_64, not aarch64. Builds from > shipilev.net > > erroneously say they are aarch64 even for x86_64 > > builds. > > Oh, wow. That's bad. We shall fix that then. And I was wondering why we > have this surge of aarch64 early adopters. > > > 2. Freezes indeed are gone. That's already good news. > > Great! > > > 3. Error with possible deadlock (from > > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still > > exists > > I will look into this right now. > > > 4. Original C2 issue is gone, nut new one appeared, please > > see?https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b > > We might need to see the corresponding replay file (with the same PID as > the hs_err file), and ideally the class files/JARs involved in this. > > Thanks, > Roman > > > Alexey > > > > On Wed, 13 Nov 2019 at 14:06, Roman Kennke > > >> wrote: > > > >? ? ?I just realized that in your latest test you used a Zero VM. > This is > >? ? ?most likely not what you wanted ;-) > > > >? ? ?Please try: > > > >? ? ?Release build: > >? ? > ?https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz > > > >? ? ?Fastdebug build: > >? ? > ?https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz > > > >? ? ?Thanks, > >? ? ?Roman > > > > > >? ? ?> Hello, Shenandoah devs. > >? ? ?> I updated jdk8 from 191-b12 to 232-b09 and started to get > spurious > >? ? ?freezes > >? ? ?> of my application during startup which occur pretty > consistently. > >? ? ?Digging > >? ? ?> into gave me impression that is something wrong with java > itself. > >? ? ?Having > >? ? ?> tried to use fastdebug build I started to get these hs_err.logs: > >? ? ?> https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180 > >? ? ?> https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd > >? ? ?> and another possible outcome is same as earlier - hung jvm which > >? ? ?heavily > >? ? ?> consumes CPU in GC threads with a stacktrace like that (got it > >? ? ?with perf): > >? ? ?> 32.32%? libjvm.so? ? ?[.] ShenandoahAsserts::assert_correct > >? ? ?> 16.16%? libjvm.so? ? ?[.] ShenandoahBarrierSet::write_barrier > >? ? ?> 10.10%? libjvm.so? ? ?[.] JvmtiTagMap::do_weak_oops > >? ? ?> 8.43%? libjvm.so? ? ? [.] > >? ? ?ShenandoahForwardedIsAliveClosure::do_object_b > >? ? ?> 8.25%? libjvm.so? ? ? [.] > >? ? ?> ShenandoahEvacuateUpdateRootsClosure::do_oop_work > >? ? ?> 6.71%? libjvm.so? ? ? [.] ShenandoahHeap::in_collection_set > >? ? ?> 6.16%? libjvm.so? ? ? [.] ShenandoahHeap::is_in > >? ? ?> 5.53%? libjvm.so? ? ? [.] Metaspace::contains > >? ? ?> 2.70%? libjvm.so? ? ? [.] ShenandoahHeap::heap > >? ? ?> 2.43%? libjvm.so? ? ? [.] ShenandoahHeap::kind > >? ? ?> 0.76%? libjvm.so? ? ? [.] ShenandoahHeap::heap_no_check > >? ? ?> 0.24%? [kernel]? ? ? ?[k] trigger_load_balance > >? ? ?> 0.14%? [kernel]? ? ? ?[k] system_call_fastpath > >? ? ?> > >? ? ?> Aleksey Shipilev suggested running on latest > shenandoah-backport. > >? ? ?I did it > >? ? ?> and it gave me another error in 100% cases (probably > unrelated to > >? ? ?original > >? ? ?> error). The log is here > >? ? ?> https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b > >? ? ?> > >? ? ?> Moving back to 1.8.0.192 helps, but maybe we can find the > error here. > >? ? ?> Unfortunately I don't haven a minimal reproducible example, but > >? ? ?I'm open to > >? ? ?> any suggestions on how to make it. > >? ? ?> Do you have any thoughts about how to fix this? > >? ? ?> > >? ? ?> Alexey > >? ? ?> > > > From rkennke at redhat.com Wed Nov 13 20:30:33 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Nov 2019 21:30:33 +0100 Subject: RFR (sh/8): Missing include in shenandoahOopClosures.cpp Message-ID: This file came with Traversal GC, and is specific to sh/jdk8. It must include precompiled.hpp otherwise we get build failures on Windows. diff -r 282516993f97 src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp --- a/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp Wed Nov 13 12:27:29 2019 +0100 +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp Wed Nov 13 21:27:18 2019 +0100 @@ -21,6 +21,7 @@ * */ +#include "precompiled.hpp" #include "gc_implementation/shenandoah/shenandoahHeap.inline.hpp" #include "gc_implementation/shenandoah/shenandoahOopClosures.hpp" #include "runtime/thread.hpp" Ok? Roman From zgu at redhat.com Wed Nov 13 20:31:45 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 Nov 2019 15:31:45 -0500 Subject: RFR (sh/8): Missing include in shenandoahOopClosures.cpp In-Reply-To: References: Message-ID: Looks good. Thanks, -Zhengyu On 11/13/19 3:30 PM, Roman Kennke wrote: > This file came with Traversal GC, and is specific to sh/jdk8. It must > include precompiled.hpp otherwise we get build failures on Windows. > > diff -r 282516993f97 > src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp > --- > a/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp > Wed Nov 13 12:27:29 2019 +0100 > +++ > b/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp > Wed Nov 13 21:27:18 2019 +0100 > @@ -21,6 +21,7 @@ > ? * > ? */ > > +#include "precompiled.hpp" > ?#include "gc_implementation/shenandoah/shenandoahHeap.inline.hpp" > ?#include "gc_implementation/shenandoah/shenandoahOopClosures.hpp" > ?#include "runtime/thread.hpp" > > > Ok? > > Roman > From rkennke at redhat.com Wed Nov 13 20:34:31 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 13 Nov 2019 20:34:31 +0000 Subject: hg: shenandoah/jdk8/hotspot: Add missing include in shenandoahOopClosures.cpp Message-ID: <201911132034.xADKYVZB004935@aojmv0008.oracle.com> Changeset: 4095ba341695 Author: rkennke Date: 2019-11-13 21:37 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4095ba341695 Add missing include in shenandoahOopClosures.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp From zgu at redhat.com Wed Nov 13 20:41:22 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 Nov 2019 15:41:22 -0500 Subject: [11] RFR/RFC: Pick up 11.0.6+2 to sh/jdk11 In-Reply-To: References: Message-ID: <5684ec9c-db3b-1eb7-d2dc-81cf43df52d4@redhat.com> Okay. Thanks, -Zhengyu On 11/13/19 7:55 AM, Roman Kennke wrote: > 11u updates project had tagged the 11.0.6+2, which includes a bunch of > outstanding changes in 11u project. Let's pick those up. > > The merge was trivial. > > Changeset list: > http://cr.openjdk.java.net/~rkennke/sh-jdk11-11.0.6%2b02/changesets.txt > > Testing: hotspot_gc_shenandoah {fastdebug,release} > > I'd push the tag shenandoah-jdk-11.0.6+2 together with this merge. > > Ok? > > Roman > From rkennke at redhat.com Wed Nov 13 20:43:02 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 13 Nov 2019 20:43:02 +0000 Subject: hg: shenandoah/jdk11: 16 new changesets Message-ID: <201911132043.xADKh4eW009880@aojmv0008.oracle.com> Changeset: d33e640c1c75 Author: egahlin Date: 2019-01-04 14:05 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d33e640c1c75 8215771: The jfr tool should pretty print reference chains Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java Changeset: cdb17b468065 Author: cito Date: 2019-10-22 23:55 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cdb17b468065 8223697: jfr tool can't format duration values greater than 1 minute Reviewed-by: egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java Changeset: 1df14c3bcf45 Author: goetz Date: 2019-10-30 10:26 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1df14c3bcf45 Merge Changeset: bd98aa23becd Author: ihse Date: 2018-12-03 18:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/bd98aa23becd 8214311: dtrace gensrc has missing dependencies Reviewed-by: tbell, erikj, clanger ! make/Main.gmk ! make/hotspot/gensrc/GensrcDtrace.gmk Changeset: 79c2c04e52d2 Author: gromero Date: 2018-09-14 15:32 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/79c2c04e52d2 8209972: [GRAAL] Don't run RTM tests with Graal Reviewed-by: kvn, goetz ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestRTMAbortThresholdOption.java ! test/hotspot/jtreg/compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java ! test/hotspot/jtreg/compiler/rtm/cli/TestRTMLockingThresholdOption.java ! test/hotspot/jtreg/compiler/rtm/cli/TestRTMRetryCountOption.java ! test/hotspot/jtreg/compiler/rtm/cli/TestRTMSpinLoopCountOption.java ! test/hotspot/jtreg/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java ! test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMAbortRatio.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMAbortThreshold.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMLockingCalculationDelay.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMLockingThreshold.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMRetryCount.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMSpinLoopCount.java ! test/hotspot/jtreg/compiler/rtm/locking/TestRTMTotalCountIncrRate.java ! test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMAfterLockInflation.java ! test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMDeopt.java ! test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMForInflatedLocks.java ! test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMForStackLocks.java ! test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMXendForLockBusy.java ! test/hotspot/jtreg/compiler/rtm/method_options/TestNoRTMLockElidingOption.java ! test/hotspot/jtreg/compiler/rtm/method_options/TestUseRTMLockElidingOption.java ! test/hotspot/jtreg/compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java ! test/jtreg-ext/requires/VMProps.java Changeset: 7060495cb852 Author: prr Date: 2019-10-30 15:57 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/7060495cb852 8212071: Need to set the FreeType LCD Filter to reduce fringing. Reviewed-by: prr, lbourges Contributed-by: John Neffenger ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: a56320c01d34 Author: dtitov Date: 2019-03-28 04:30 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/a56320c01d34 8221532: Incorrect copyright header in FileSystemSupport_md.c Reviewed-by: cjplummer, gadams ! src/java.instrument/unix/native/libinstrument/FileSystemSupport_md.c ! src/java.instrument/windows/native/libinstrument/FileSystemSupport_md.c Changeset: 9f9baf5582b2 Author: gadams Date: 2019-03-12 11:53 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/9f9baf5582b2 8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java Reviewed-by: dholmes ! src/java.instrument/share/classes/java/lang/instrument/package-info.java Changeset: 46477b4dad6d Author: bobv Date: 2019-03-08 16:21 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/46477b4dad6d 8220476: Incorrect GPL header in src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Reviewed-by: lancea ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Changeset: 9215b217c64b Author: mdoerr Date: 2019-01-15 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/9215b217c64b 8216426: Usage of array placement new may lead to memory corruption Reviewed-by: rehn, kbarrett, rkennke, eosterlund ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: c7a422d25b06 Author: neliasso Date: 2018-12-04 18:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c7a422d25b06 8214773: Replace use of thread unsafe strtok Reviewed-by: thartmann, dholmes ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/memory/universe.cpp Changeset: f2b580a5721c Author: mbalao Date: 2019-06-05 01:42 -0300 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/f2b580a5721c 8215032: Support Kerberos cross-realm referrals (RFC 6806) Reviewed-by: weijun ! src/java.base/share/conf/security/java.security ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbAsRep.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReq.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbKdcRep.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsRep.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsReq.java ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/EncASRepPart.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/EncTGSRepPart.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCReq.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/PAData.java + src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/TicketFlags.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! test/jdk/sun/security/krb5/auto/KDC.java + test/jdk/sun/security/krb5/auto/ReferralsTest.java Changeset: 8d3e0c2c0098 Author: roland Date: 2019-10-01 10:28 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8d3e0c2c0098 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/loopopts/SplitIfSharedFastLockBehindCastPP.java Changeset: be745617e8c4 Author: goetz Date: 2019-11-06 08:02 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/be745617e8c4 Added tag jdk-11.0.6+2 for changeset 8d3e0c2c0098 ! .hgtags Changeset: 841e3651fd3b Author: rkennke Date: 2019-11-13 13:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/841e3651fd3b Merge ! .hgtags ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/split_if.cpp ! test/hotspot/jtreg/TEST.ROOT Changeset: 24696c9b9b1d Author: rkennke Date: 2019-11-13 21:45 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/24696c9b9b1d Added tag shenandoah-jdk-11.0.6+2 for changeset 841e3651fd3b ! .hgtags From rwestrel at redhat.com Thu Nov 14 12:32:10 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Nov 2019 13:32:10 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> Message-ID: <87v9rmd4fp.fsf@redhat.com> Hi Alexey, > I uploaded replay file for that very run > https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > Attached file is the class-file which caused error. This is an unusual > class which was generated by one-nio > in this method > Thanks for providing the replay file but if a generated class file is involved that won't help, unfortunately. Is there a way for us to reproduce this locally? Roland. From genus.alexey at gmail.com Thu Nov 14 17:36:03 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Thu, 14 Nov 2019 20:36:03 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: <87v9rmd4fp.fsf@redhat.com> References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> Message-ID: Hi Roland, > Thanks for providing the replay file but if a generated class file is > involved that won't help, unfortunately. > Is there a way for us to reproduce this locally? I created an empty repo https://github.com/genuss/jdk8u232-minimal with mininal code and it breaks C2 on my machine even without Shenandoah enabled. I attached fat-jar to release on github so you won't need to build it https://github.com/genuss/jdk8u232-minimal/releases/tag/1.0. To run simply use java -jar minimal-example-1.0.0-jar-with-dependencies.jar Roman, I tried nightly build with no luck unfortunately. Both crashes still present. On Thu, 14 Nov 2019 at 15:32, Roland Westrelin wrote: > > Hi Alexey, > > > I uploaded replay file for that very run > > https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > > Attached file is the class-file which caused error. This is an unusual > > class which was generated by one-nio > > in this method > > < > https://github.com/odnoklassniki/one-nio/blob/master/src/one/nio/serial/gen/DelegateGenerator.java#L115 > > > > Thanks for providing the replay file but if a generated class file is > involved that won't help, unfortunately. > > Is there a way for us to reproduce this locally? > > Roland. > > From rkennke at redhat.com Thu Nov 14 18:00:41 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Nov 2019 19:00:41 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> Message-ID: <0d7f09b8-f23f-05e7-d2d2-58122b129277@redhat.com> Hi Alexey, > Roman, > I tried nightly build with no luck unfortunately. Both crashes still > present. Yes. But they can only happen with a fastdebug build, right? As far as I can tell, the lock-ordering-problem should be non-fatal, so with a release build (which doesn't have the assert) you should be able to make progress. I am working on a fix for the lock-ordering problem. I do have a testcase and a fix candidate that I'm currently testing. Thanks, Roman > On Thu, 14 Nov 2019 at 15:32, Roland Westrelin > wrote: > > > Hi Alexey, > > > I uploaded replay file for that very run > > https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > > Attached file is the class-file which caused error. This is an unusual > > class which was generated by one-nio > > in this method > > > > > Thanks for providing the replay file but if a generated class file is > involved that won't help, unfortunately. > > Is there a way for us to reproduce this locally? > > Roland. > From genus.alexey at gmail.com Thu Nov 14 21:19:00 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Fri, 15 Nov 2019 00:19:00 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: <0d7f09b8-f23f-05e7-d2d2-58122b129277@redhat.com> References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <0d7f09b8-f23f-05e7-d2d2-58122b129277@redhat.com> Message-ID: > > > Yes. But they can only happen with a fastdebug build, right? As far as I > can tell, the lock-ordering-problem should be non-fatal, so with a > release build (which doesn't have the assert) you should be able to make > progress. > Roman, you are indeed right. With latest release build there are no freezes or crashes! Thank you, that's great! Alexey On Thu, 14 Nov 2019 at 21:00, Roman Kennke wrote: > Hi Alexey, > > > Roman, > > I tried nightly build with no luck unfortunately. Both crashes still > > present. > > Yes. But they can only happen with a fastdebug build, right? As far as I > can tell, the lock-ordering-problem should be non-fatal, so with a > release build (which doesn't have the assert) you should be able to make > progress. > > I am working on a fix for the lock-ordering problem. I do have a > testcase and a fix candidate that I'm currently testing. > > Thanks, > Roman > > > On Thu, 14 Nov 2019 at 15:32, Roland Westrelin > > wrote: > > > > > > Hi Alexey, > > > > > I uploaded replay file for that very run > > > https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > > > Attached file is the class-file which caused error. This is an > unusual > > > class which was generated by one-nio > > > in this method > > > > > < > https://github.com/odnoklassniki/one-nio/blob/master/src/one/nio/serial/gen/DelegateGenerator.java#L115 > > > > > > Thanks for providing the replay file but if a generated class file is > > involved that won't help, unfortunately. > > > > Is there a way for us to reproduce this locally? > > > > Roland. > > > > From rkennke at redhat.com Thu Nov 14 21:43:33 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Nov 2019 22:43:33 +0100 Subject: RFR (sh/8): Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking Message-ID: <4855bd41-37bb-d42d-12e7-fb6b5f04413a@redhat.com> Alexey Genus reported a lock ordering issue involving JVMTI GetLoadedClasses() during concurrent marking. ClassLoaderData::loaded_classes_do() acquires the "Metaspace allocation lock/5" and LoadedClassesClosure tries to enqueue it into G1's SATB queue, thus attempts to acquire "SATB_Q_CBL_mon/16" It is not Shenandoah specific, but would also affect G1. See discussion and G1 testcase: https://bugs.openjdk.java.net/browse/JDK-8234096 However, it is jdk8u specific. It's been fixed in jdk10 timeframe by making loaded-classes-iteration lock-free. As far as I can tell, it is not fatal in release build, but it seems prudent to fix it anyway, especially because the fix is not difficult. Simply not enqueue the oops during loaded_classes_do() but instead during extraction of the jclasses, where the Metaspace allocation lock is not held. While this could go completely via upstream jdk8u, I'd like to push this in Shenandoah first, to get it into the hands of Alexey for testing, and to bake it a little. Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8234096-shenandoah/webrev.00/ Testing: The provided testcase fails without the fix, and passes with the fix. hotspot_gc_shenandoah looks good. Ok to push? Roman From zgu at redhat.com Thu Nov 14 21:47:12 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 14 Nov 2019 16:47:12 -0500 Subject: RFR (sh/8): Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking In-Reply-To: <4855bd41-37bb-d42d-12e7-fb6b5f04413a@redhat.com> References: <4855bd41-37bb-d42d-12e7-fb6b5f04413a@redhat.com> Message-ID: Good to me. Thanks, -Zhengyu On 11/14/19 4:43 PM, Roman Kennke wrote: > Alexey Genus reported a lock ordering issue involving JVMTI > GetLoadedClasses() during concurrent marking. > > ClassLoaderData::loaded_classes_do() acquires the "Metaspace allocation > lock/5" and LoadedClassesClosure tries to enqueue it into G1's SATB > queue, thus attempts to acquire "SATB_Q_CBL_mon/16" > > It is not Shenandoah specific, but would also affect G1. See discussion > and G1 testcase: > https://bugs.openjdk.java.net/browse/JDK-8234096 > > However, it is jdk8u specific. It's been fixed in jdk10 timeframe by > making loaded-classes-iteration lock-free. > > As far as I can tell, it is not fatal in release build, but it seems > prudent to fix it anyway, especially because the fix is not difficult. > Simply not enqueue the oops during loaded_classes_do() but instead > during extraction of the jclasses, where the Metaspace allocation lock > is not held. > > While this could go completely via upstream jdk8u, I'd like to push this > in Shenandoah first, to get it into the hands of Alexey for testing, and > to bake it a little. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8234096-shenandoah/webrev.00/ > > Testing: The provided testcase fails without the fix, and passes with > the fix. hotspot_gc_shenandoah looks good. > > Ok to push? > > Roman > From rkennke at redhat.com Thu Nov 14 21:52:32 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Thu, 14 Nov 2019 21:52:32 +0000 Subject: hg: shenandoah/jdk8/hotspot: Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking Message-ID: <201911142152.xAELqWK1028891@aojmv0008.oracle.com> Changeset: e90e85d7d6bf Author: rkennke Date: 2019-11-14 22:35 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e90e85d7d6bf Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! test/TEST.groups + test/gc/shenandoah/jvmti/TestGetLoadedClasses.java + test/gc/shenandoah/jvmti/TestGetLoadedClasses.sh + test/gc/shenandoah/jvmti/libTestGetLoadedClasses.c From rkennke at redhat.com Thu Nov 14 22:32:33 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Nov 2019 23:32:33 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <0d7f09b8-f23f-05e7-d2d2-58122b129277@redhat.com> Message-ID: <270fd02f-d7f0-3449-761e-7df4ca732a4a@redhat.com> Hi Alexey, And meanwhile I pushed the fix for the lock ordering issue. It should appear in one of the next nightlies. https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-November/011092.html Roland is investigating the C2 crash. Thanks, Roman > Yes. But they can only happen with a fastdebug build, right? As far as I > can tell, the lock-ordering-problem should be non-fatal, so with a > release build (which doesn't have the assert) you should be able to make > progress. > > > Roman, you are indeed right. With latest release build there are no > freezes or crashes! Thank you, that's great!? > > Alexey > > On Thu, 14 Nov 2019 at 21:00, Roman Kennke > wrote: > > Hi Alexey, > > > Roman, > > I tried nightly build with no luck unfortunately. Both crashes still > > present. > > Yes. But they can only happen with a fastdebug build, right? As far as I > can tell, the lock-ordering-problem should be non-fatal, so with a > release build (which doesn't have the assert) you should be able to make > progress. > > I am working on a fix for the lock-ordering problem. I do have a > testcase and a fix candidate that I'm currently testing. > > Thanks, > Roman > > > On Thu, 14 Nov 2019 at 15:32, Roland Westrelin > > > >> wrote: > > > > > >? ? ?Hi Alexey, > > > >? ? ?> I uploaded replay file for that very run > >? ? ?> https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > >? ? ?> Attached file is the class-file which caused error. This is > an unusual > >? ? ?> class which was generated by one-nio > >? ? ?> in this method > >? ? ?> > >? ? > ? > > > >? ? ?Thanks for providing the replay file but if a generated class > file is > >? ? ?involved that won't help, unfortunately. > > > >? ? ?Is there a way for us to reproduce this locally? > > > >? ? ?Roland. > > > From genus.alexey at gmail.com Fri Nov 15 06:37:50 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Fri, 15 Nov 2019 09:37:50 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: <270fd02f-d7f0-3449-761e-7df4ca732a4a@redhat.com> References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <0d7f09b8-f23f-05e7-d2d2-58122b129277@redhat.com> <270fd02f-d7f0-3449-761e-7df4ca732a4a@redhat.com> Message-ID: > > And meanwhile I pushed the fix for the lock ordering issue. It should > appear in one of the next nightlies. Roman, I just checked latest fastdebug and lock ordering issue is gone. Awesome! On Fri, 15 Nov 2019 at 01:32, Roman Kennke wrote: > Hi Alexey, > > And meanwhile I pushed the fix for the lock ordering issue. It should > appear in one of the next nightlies. > > > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-November/011092.html > > Roland is investigating the C2 crash. > > Thanks, > Roman > > > Yes. But they can only happen with a fastdebug build, right? As far > as I > > can tell, the lock-ordering-problem should be non-fatal, so with a > > release build (which doesn't have the assert) you should be able to > make > > progress. > > > > > > Roman, you are indeed right. With latest release build there are no > > freezes or crashes! Thank you, that's great! > > > > Alexey > > > > On Thu, 14 Nov 2019 at 21:00, Roman Kennke > > wrote: > > > > Hi Alexey, > > > > > Roman, > > > I tried nightly build with no luck unfortunately. Both crashes > still > > > present. > > > > Yes. But they can only happen with a fastdebug build, right? As far > as I > > can tell, the lock-ordering-problem should be non-fatal, so with a > > release build (which doesn't have the assert) you should be able to > make > > progress. > > > > I am working on a fix for the lock-ordering problem. I do have a > > testcase and a fix candidate that I'm currently testing. > > > > Thanks, > > Roman > > > > > On Thu, 14 Nov 2019 at 15:32, Roland Westrelin > > > > > >> wrote: > > > > > > > > > Hi Alexey, > > > > > > > I uploaded replay file for that very run > > > > > https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > > > > Attached file is the class-file which caused error. This is > > an unusual > > > > class which was generated by one-nio > > > > in this method > > > > > > > > > < > https://github.com/odnoklassniki/one-nio/blob/master/src/one/nio/serial/gen/DelegateGenerator.java#L115 > > > > > > > > Thanks for providing the replay file but if a generated class > > file is > > > involved that won't help, unfortunately. > > > > > > Is there a way for us to reproduce this locally? > > > > > > Roland. > > > > > > > From rwestrel at redhat.com Fri Nov 15 09:10:14 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Nov 2019 10:10:14 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> Message-ID: <87pnhtcxop.fsf@redhat.com> > I created an empty repo https://github.com/genuss/jdk8u232-minimal with > mininal code and it breaks C2 on my machine even without Shenandoah > enabled. I attached fat-jar to release on github so you won't need to build > it https://github.com/genuss/jdk8u232-minimal/releases/tag/1.0. To run > simply use java -jar minimal-example-1.0.0-jar-with-dependencies.jar Thanks for putting that together. The bytecode that C2 compiles doesn't seem correct: one.nio.serial.GeneratedSerializer::write 0 fast_aaccess_0 1 fast_agetfield 11 4 aload_1 5 aload_2 6 invokeinterface 38 11 return calls: sun.reflect.Delegate1_BigInteger::write 0 aload_2 1 aload_1 2 fast_igetfield 35 ... Argument 1 of GeneratedSerializer::write is of type java.lang.Object but field being accessed at bci 2 in Delegate1_BigInteger::write is from a BigInteger. A cast to BigInteger seems to be missing. Roland. From rkennke at redhat.com Fri Nov 15 09:34:50 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Nov 2019 10:34:50 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <0d7f09b8-f23f-05e7-d2d2-58122b129277@redhat.com> <270fd02f-d7f0-3449-761e-7df4ca732a4a@redhat.com> Message-ID: <6c428367-4e58-06b3-438e-c2235985c642@redhat.com> Hi Alexey, > And meanwhile I pushed the fix for the lock ordering issue. It should > appear in one of the next nightlies. > > Roman, I just checked latest fastdebug and lock ordering issue is gone. > Awesome! Great! Thanks for testing and confirming it! Let us know if you encounter any other problems, ok? Thanks, Roman > On Fri, 15 Nov 2019 at 01:32, Roman Kennke > wrote: > > Hi Alexey, > > And meanwhile I pushed the fix for the lock ordering issue. It should > appear in one of the next nightlies. > > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-November/011092.html > > Roland is investigating the C2 crash. > > Thanks, > Roman > > >? ? ?Yes. But they can only happen with a fastdebug build, right? > As far as I > >? ? ?can tell, the lock-ordering-problem should be non-fatal, so with a > >? ? ?release build (which doesn't have the assert) you should be > able to make > >? ? ?progress. > > > > > > Roman, you are indeed right. With latest release build there are no > > freezes or crashes! Thank you, that's great!? > > > > Alexey > > > > On Thu, 14 Nov 2019 at 21:00, Roman Kennke > > >> wrote: > > > >? ? ?Hi Alexey, > > > >? ? ?> Roman, > >? ? ?> I tried nightly build with no luck unfortunately. Both > crashes still > >? ? ?> present. > > > >? ? ?Yes. But they can only happen with a fastdebug build, right? > As far as I > >? ? ?can tell, the lock-ordering-problem should be non-fatal, so with a > >? ? ?release build (which doesn't have the assert) you should be > able to make > >? ? ?progress. > > > >? ? ?I am working on a fix for the lock-ordering problem. I do have a > >? ? ?testcase and a fix candidate that I'm currently testing. > > > >? ? ?Thanks, > >? ? ?Roman > > > >? ? ?> On Thu, 14 Nov 2019 at 15:32, Roland Westrelin > >? ? ? > > > >? ? ?> > >>> wrote: > >? ? ?> > >? ? ?> > >? ? ?>? ? ?Hi Alexey, > >? ? ?> > >? ? ?>? ? ?> I uploaded replay file for that very run > >? ? ?>? ? ?> > https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648 > >? ? ?>? ? ?> Attached file is the class-file which caused error. > This is > >? ? ?an unusual > >? ? ?>? ? ?> class which was generated by one-nio > >? ? ?>? ? ?> in this method > >? ? ?>? ? ?> > >? ? ?>? ? > >? ? > ?? > >? ? ?> > >? ? ?>? ? ?Thanks for providing the replay file but if a generated > class > >? ? ?file is > >? ? ?>? ? ?involved that won't help, unfortunately. > >? ? ?> > >? ? ?>? ? ?Is there a way for us to reproduce this locally? > >? ? ?> > >? ? ?>? ? ?Roland. > >? ? ?> > > > From rkennke at redhat.com Fri Nov 15 09:37:05 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Nov 2019 10:37:05 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: <87pnhtcxop.fsf@redhat.com> References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <87pnhtcxop.fsf@redhat.com> Message-ID: Hi Roland, >> I created an empty repo https://github.com/genuss/jdk8u232-minimal with >> mininal code and it breaks C2 on my machine even without Shenandoah >> enabled. I attached fat-jar to release on github so you won't need to build >> it https://github.com/genuss/jdk8u232-minimal/releases/tag/1.0. To run >> simply use java -jar minimal-example-1.0.0-jar-with-dependencies.jar > > Thanks for putting that together. > > The bytecode that C2 compiles doesn't seem correct: > > one.nio.serial.GeneratedSerializer::write > > 0 fast_aaccess_0 > 1 fast_agetfield 11 > 4 aload_1 > 5 aload_2 > 6 invokeinterface 38 > 11 return > > calls: > > sun.reflect.Delegate1_BigInteger::write > > 0 aload_2 > 1 aload_1 > 2 fast_igetfield 35 > > ... > > Argument 1 of GeneratedSerializer::write is of type java.lang.Object but > field being accessed at bci 2 in Delegate1_BigInteger::write is from a > BigInteger. A cast to BigInteger seems to be missing. In other words, this appears to be an issue that should be reported upstream to one-nio. Right? Thanks, Roman From alex at bytopia.org Fri Nov 15 09:59:08 2019 From: alex at bytopia.org (Alexander Yakushev) Date: Fri, 15 Nov 2019 11:59:08 +0200 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> <8ee880f9-bc96-4349-c13f-b433fa746ad8@redhat.com> Message-ID: Hello Roman, Sorry, I didn't have a chance to continue the investigation. We've reverted to Shenandoah 1.0 since then and researched what it takes to move this particular service to JDK11 (which is a good idea anyway). I've noticed on Twitter that you managed to trigger a similar problem with Netty in the same method (ScheduleFutureTask.cancel). Did it lead anywhere? From rkennke at redhat.com Fri Nov 15 10:49:54 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Nov 2019 11:49:54 +0100 Subject: SIGSEGV crash in ObjectMonitor::enter with latest Shenandoah JDK8 In-Reply-To: References: <764f9829-4727-1d10-7218-17e18349ff0d@redhat.com> <8ee880f9-bc96-4349-c13f-b433fa746ad8@redhat.com> Message-ID: <863be849-3212-acc2-fc38-2c8d80531d89@redhat.com> Hi Alexander, > Sorry, I didn't have a chance to continue the investigation. We've > reverted to Shenandoah 1.0 since then and researched what it takes to > move this particular service to JDK11 (which is a good idea anyway). Hmm, ok. I'd sleep better if I could fix this bug. Or at least, reproduce it. Or know if it's still present, even. > I've noticed on Twitter that you managed to trigger a similar problem > with Netty in the same method (ScheduleFutureTask.cancel). Did it lead > anywhere? No. This was an attempt to reproduce your problem. But I did not manage to reproduce it so far. I'll keep digging. Thanks, Roman From rwestrel at redhat.com Mon Nov 18 08:29:16 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Nov 2019 09:29:16 +0100 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <87pnhtcxop.fsf@redhat.com> Message-ID: <874kz1d1ur.fsf@redhat.com> > In other words, this appears to be an issue that should be reported > upstream to one-nio. Right? Yes. Roland. From genus.alexey at gmail.com Mon Nov 18 08:59:56 2019 From: genus.alexey at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JPQtdC90YPRgQ==?=) Date: Mon, 18 Nov 2019 11:59:56 +0300 Subject: jdk8u backport is brokent in 1.8.0.232.b09 In-Reply-To: <874kz1d1ur.fsf@redhat.com> References: <141642e7-c1ac-59f0-f27c-a829d1d9a10c@redhat.com> <87v9rmd4fp.fsf@redhat.com> <87pnhtcxop.fsf@redhat.com> <874kz1d1ur.fsf@redhat.com> Message-ID: Roman, Roland, thank you for your help! I'll dig into one-nio bytecode generator issue ASAP. One thing that bothers me is that this code is valid in terms of verifier but reported as invalid as C2. Looks like this issue is also non-fatal because it can't be reproduced in release build. The only thing is the code generated by one-nio can't be compiled by C2 which is not as bad as it might seem to be. Anyway I'm glad you could help me! Thanks again. Alexey On Mon, 18 Nov 2019 at 11:29, Roland Westrelin wrote: > > > In other words, this appears to be an issue that should be reported > > upstream to one-nio. Right? > > Yes. > > Roland. > > From fdemeloj at redhat.com Mon Nov 18 17:23:37 2019 From: fdemeloj at redhat.com (Francisco De Melo Junior) Date: Mon, 18 Nov 2019 12:23:37 -0500 Subject: Questions about Shedandoah and OpenJDK Message-ID: Hello experts, two quick questions here regarding Shenandoah releases and openjdk releases: 1) How do I know which version of the Shenandoah JVM GC is part of any particular version of the OpenJDK? 2) Which versions of the OpenJDK have the Shenandoah JVM GC version 1.0 and which versions of the OpenJDK have the Shenandoah JVM GC 2.0? Thanks. -f From rkennke at redhat.com Mon Nov 18 18:02:36 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Nov 2019 19:02:36 +0100 Subject: Questions about Shedandoah and OpenJDK In-Reply-To: References: Message-ID: <9ed17cc9-cbc4-0f11-ed0b-73b686a1e74e@redhat.com> Hi Francisco, First of all, we do not really have a versioning scheme for Shenandoah. We came to call the new Shenandoah features load-reference-barriers (LRB) and the new forwarding pointer scheme 'Shenandoah 2.0' because it is such a dramatic change in the algorithm and its properties. So, terminology here is everything before LRB is '1.0' and everything after '2.0'. > 1) How do I know which version of the Shenandoah JVM GC is part of any > particular version of the OpenJDK? > 2) Which versions of the OpenJDK have the Shenandoah JVM GC version > 1.0 and which versions of the OpenJDK have the Shenandoah JVM GC 2.0? LRB and new fwd pointer scheme have been pushed to JDK 13, and is available there. (Except Oracle builds, but that is another story.) We have also backported it to our own shenandoah/jdk11 repository, and that is available in RHEL OpenJDK packages. We've also backported it to shenandoah/jdk8, but this hasn't been released as binary yet. The Shenandoah GC in JDK 12 does not have the new features, and never will. Eventually we will propose Shenandoah GC for inclusion in JDK 11 updates and JDK 8 updates, but we don't know when that will happen, and whether it will be accepted or not. Does that answer your questions? Thanks, Roman From zgu at redhat.com Mon Nov 25 20:35:13 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 25 Nov 2019 15:35:13 -0500 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms Message-ID: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> Hi all, Please review this implementation of nmethod barrier for x86_32 platforms. x86_32 implementation mirrors x86_64's. The only difference is where it reads nmethod disarmed value. Unlike 64-bits, 32-bits platform does not have a dedicated register for current thread. So that it is cheaper to read disarmed value from global location than from per-thread GC data. Currently, only Shenandoah GC uses the implementation for its concurrent class unloading. This implementation, along with Shenandoah concurrent class unloading, has been baked in shenandoah/jdk repo for some time now, they are ready for integration. Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ Test: hotspot_gc with x86_64 and x86_32 JVM on Linux Submit test. Thanks, -Zhengyu From rkennke at redhat.com Mon Nov 25 21:07:50 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 Nov 2019 22:07:50 +0100 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> References: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> Message-ID: <3329cf09-55df-12ab-e40c-f8f9e480a1ce@redhat.com> It looks good to me, thanks! Roman > Hi all, > > Please review this implementation of nmethod barrier for x86_32 platforms. > > x86_32 implementation mirrors x86_64's. The only difference is where it > reads nmethod disarmed value. > > Unlike 64-bits, 32-bits platform does not have a dedicated register for > current thread. So that it is cheaper to read disarmed value from global > location than from per-thread GC data. > > Currently, only Shenandoah GC uses the implementation for its concurrent > class unloading. This implementation, along with Shenandoah concurrent > class unloading, has been baked in shenandoah/jdk repo for some time > now,? they are ready for integration. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ > > > Test: > ? hotspot_gc with x86_64 and x86_32 JVM on Linux > ? Submit test. > > Thanks, > > -Zhengyu > From zgu at redhat.com Mon Nov 25 22:01:15 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 25 Nov 2019 17:01:15 -0500 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <3329cf09-55df-12ab-e40c-f8f9e480a1ce@redhat.com> References: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> <3329cf09-55df-12ab-e40c-f8f9e480a1ce@redhat.com> Message-ID: Thanks, Roman. -Zhengyu On 11/25/19 4:07 PM, Roman Kennke wrote: > It looks good to me, thanks! > > Roman > > >> Hi all, >> >> Please review this implementation of nmethod barrier for x86_32 platforms. >> >> x86_32 implementation mirrors x86_64's. The only difference is where it >> reads nmethod disarmed value. >> >> Unlike 64-bits, 32-bits platform does not have a dedicated register for >> current thread. So that it is cheaper to read disarmed value from global >> location than from per-thread GC data. >> >> Currently, only Shenandoah GC uses the implementation for its concurrent >> class unloading. This implementation, along with Shenandoah concurrent >> class unloading, has been baked in shenandoah/jdk repo for some time >> now,? they are ready for integration. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ >> >> >> Test: >> ? hotspot_gc with x86_64 and x86_32 JVM on Linux >> ? Submit test. >> >> Thanks, >> >> -Zhengyu >> > From zgu at redhat.com Tue Nov 26 01:09:57 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 25 Nov 2019 20:09:57 -0500 Subject: RFR Shenandoah: Don't recycle trash regions before concurrent root processing Message-ID: <392e9b2e-47c4-e96d-5134-31ce036769c2@redhat.com> Concurrent root processing requires Collection Set kept intact, because it is needed to determine if an oop is alive or dead. Roman pointed out that our trash recycle-assist could recycle trash regions prematurely. That results some of dead oops suddenly become alive, as recycled regions becomes new regions and those dead oops are above TAMS. This problem is exhibited by is_loader_alive() assertion failure in CriticalNativeStress tests. The solution is to avoid recycling trash region before concurrent root processing is completed. Webrev: http://cr.openjdk.java.net/~zgu/early_recycle_trash/webrev.00/index.html Test: tier3_gc_shenandoah with 20 iterations, usually fails within 10 iterations without the fix. Thanks, -Zhengyu From erik.osterlund at oracle.com Tue Nov 26 10:32:02 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Tue, 26 Nov 2019 11:32:02 +0100 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> References: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> Message-ID: <8191daa9-0dfb-99a7-8433-25e3d9378082@oracle.com> Hi Zhengyu, Nice to see nmethod entry barriers added one more platform configuration. So now you use a global instead of thread-local on 32 bit x64 as it doesn't have a Thread register. That makes sense. I wonder though if that difference has spread too far into the runtime code. It does sting a bit in my eyes to read the seemingly unnecessary #ifdef _LP64 macros in BarrierSetNMethod. In particular, when computing the BarrierSetNMethod::disarmed_value(), it seems like it would work for everyone to simply read the global value, instead of doing it only sometimes, and sometimes read the thread-local. Here is a patch with my proposed cleanup: http://cr.openjdk.java.net/~eosterlund/8230765/webrev.02/ Incremental: http://cr.openjdk.java.net/~eosterlund/8230765/webrev.01_02/ Thanks, /Erik On 11/25/19 9:35 PM, Zhengyu Gu wrote: > Hi all, > > Please review this implementation of nmethod barrier for x86_32 > platforms. > > x86_32 implementation mirrors x86_64's. The only difference is where > it reads nmethod disarmed value. > > Unlike 64-bits, 32-bits platform does not have a dedicated register > for current thread. So that it is cheaper to read disarmed value from > global location than from per-thread GC data. > > Currently, only Shenandoah GC uses the implementation for its > concurrent class unloading. This implementation, along with Shenandoah > concurrent class unloading, has been baked in shenandoah/jdk repo for > some time now,? they are ready for integration. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ > > > Test: > ? hotspot_gc with x86_64 and x86_32 JVM on Linux > ? Submit test. > > Thanks, > > -Zhengyu > From rkennke at redhat.com Tue Nov 26 11:36:49 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 Nov 2019 12:36:49 +0100 Subject: RFR Shenandoah: Don't recycle trash regions before concurrent root processing In-Reply-To: <392e9b2e-47c4-e96d-5134-31ce036769c2@redhat.com> References: <392e9b2e-47c4-e96d-5134-31ce036769c2@redhat.com> Message-ID: Looks good, thanks! Roman > Concurrent root processing requires Collection Set kept intact, because > it is needed to determine if an oop is alive or dead. > > Roman pointed out that our trash recycle-assist could recycle trash > regions prematurely. That results some of dead oops suddenly become > alive, as recycled regions becomes new regions and those dead oops are > above TAMS. This problem is exhibited by is_loader_alive() assertion > failure in CriticalNativeStress tests. > > The solution is to avoid recycling trash region before concurrent root > processing is completed. > > Webrev: > http://cr.openjdk.java.net/~zgu/early_recycle_trash/webrev.00/index.html > > Test: > ? tier3_gc_shenandoah with 20 iterations, usually fails within 10 > iterations without the fix. > > Thanks, > > -Zhengyu > From zgu at redhat.com Tue Nov 26 13:24:08 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 Nov 2019 08:24:08 -0500 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <8191daa9-0dfb-99a7-8433-25e3d9378082@oracle.com> References: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> <8191daa9-0dfb-99a7-8433-25e3d9378082@oracle.com> Message-ID: <8232be6d-1942-ab42-b72a-6f92bafd70f9@redhat.com> Hi Erik, Thanks for the reviewing and suggestion. On 11/26/19 5:32 AM, erik.osterlund at oracle.com wrote: > Hi Zhengyu, > > Nice to see nmethod entry barriers added one more platform configuration. > So now you use a global instead of thread-local on 32 bit x64 as it > doesn't have a Thread register. > That makes sense. I wonder though if that difference has spread too far > into the runtime code. It does > sting a bit in my eyes to read the seemingly unnecessary #ifdef _LP64 > macros in BarrierSetNMethod. > > In particular, when computing the BarrierSetNMethod::disarmed_value(), > it seems like it would work > for everyone to simply read the global value, instead of doing it only > sometimes, and sometimes read > the thread-local. > > Here is a patch with my proposed cleanup: > http://cr.openjdk.java.net/~eosterlund/8230765/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8230765/webrev.01_02/ > Yes, this indeed a much cleaner approach. I will take your proposed cleanup and run through submit. -Zhengyu > Thanks, > /Erik > > On 11/25/19 9:35 PM, Zhengyu Gu wrote: >> Hi all, >> >> Please review this implementation of nmethod barrier for x86_32 >> platforms. >> >> x86_32 implementation mirrors x86_64's. The only difference is where >> it reads nmethod disarmed value. >> >> Unlike 64-bits, 32-bits platform does not have a dedicated register >> for current thread. So that it is cheaper to read disarmed value from >> global location than from per-thread GC data. >> >> Currently, only Shenandoah GC uses the implementation for its >> concurrent class unloading. This implementation, along with Shenandoah >> concurrent class unloading, has been baked in shenandoah/jdk repo for >> some time now,? they are ready for integration. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ >> >> >> Test: >> ? hotspot_gc with x86_64 and x86_32 JVM on Linux >> ? Submit test. >> >> Thanks, >> >> -Zhengyu >> > From rkennke at redhat.com Tue Nov 26 13:48:19 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 Nov 2019 14:48:19 +0100 Subject: RFR: 8234768: Shenandoah: Streamline enqueueing runtime barriers Message-ID: Shenandoah's runtime barriers for SATB pre-date the GC interface, and have been very coarsly fitted into the new GC interfaces. It leaves room for improvements: - Rename methods to make more sense - Group enqueueing barrier methods together - Make them inlinable, including the ultimate enqueue() method - Avoid barriers on DEST_UNINITIALIZED pre-barriers - Benefit from static resolution of decorators when possible, and don't generate barriers at all in those cases As a bonus, add SATB and traversal store-value barriers to native oop stores. This is not doing anything now, but will enable concurrent roots scanning in the near future. Bug: https://bugs.openjdk.java.net/browse/JDK-8234768 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8234768/webrev.00/ Can I please get a review? Thanks, Roman From zgu at redhat.com Tue Nov 26 14:00:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 Nov 2019 09:00:11 -0500 Subject: RFR: 8234768: Shenandoah: Streamline enqueueing runtime barriers In-Reply-To: References: Message-ID: Nice cleanup and looks good to me. Thanks, -Zhengyu On 11/26/19 8:48 AM, Roman Kennke wrote: > Shenandoah's runtime barriers for SATB pre-date the GC interface, and > have been very coarsly fitted into the new GC interfaces. It leaves room > for improvements: > - Rename methods to make more sense > - Group enqueueing barrier methods together > - Make them inlinable, including the ultimate enqueue() method > - Avoid barriers on DEST_UNINITIALIZED pre-barriers > - Benefit from static resolution of decorators when possible, and don't > generate barriers at all in those cases > > As a bonus, add SATB and traversal store-value barriers to native oop > stores. This is not doing anything now, but will enable concurrent roots > scanning in the near future. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234768 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8234768/webrev.00/ > > Can I please get a review? > > Thanks, > Roman > From zgu at redhat.com Tue Nov 26 15:46:48 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 26 Nov 2019 15:46:48 +0000 Subject: hg: shenandoah/jdk: Shenandoah: Don't recycle trash regions before concurrent root processing Message-ID: <201911261546.xAQFkm4I029967@aojmv0008.oracle.com> Changeset: a5aa4d967725 Author: zgu Date: 2019-11-26 10:46 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk/rev/a5aa4d967725 Shenandoah: Don't recycle trash regions before concurrent root processing Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp From rkennke at redhat.com Tue Nov 26 16:30:58 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 Nov 2019 17:30:58 +0100 Subject: RFR (sh/8): Remove to wrong handlings of Shenandoah LRB in escape analysis Message-ID: <76643e45-ae70-5a0d-4e32-7bc7b53fd434@redhat.com> Before I forget (because it is not tracked), here is the backport of a recent fix that I did in 11. It has baked there for 2 weeks now. ok to push? Thanks, Roman # HG changeset patch # User rkennke # Date 1574785684 -3600 # Tue Nov 26 17:28:04 2019 +0100 # Node ID b9601b57b3c413454c93cbee75739bc75fee6f20 # Parent e90e85d7d6bfcfaaeb89d38e8d8b9fae2eed4c73 [backport] Remove to wrong handlings of Shenandoah LRB in escape analysis diff -r e90e85d7d6bf -r b9601b57b3c4 src/share/vm/opto/escape.cpp --- a/src/share/vm/opto/escape.cpp Thu Nov 14 22:35:14 2019 +0100 +++ b/src/share/vm/opto/escape.cpp Tue Nov 26 17:28:04 2019 +0100 @@ -2991,7 +2991,6 @@ n->is_CheckCastPP() || n->is_EncodeP() || n->is_DecodeN() || - n->Opcode() == Op_ShenandoahLoadReferenceBarrier || (n->is_ConstraintCast() && n->Opcode() == Op_CastPP)) { if (visited.test_set(n->_idx)) { assert(n->is_Phi(), "loops only through Phi's"); @@ -3062,7 +3061,6 @@ use->is_CheckCastPP() || use->is_EncodeNarrowPtr() || use->is_DecodeNarrowPtr() || - use->Opcode() == Op_ShenandoahLoadReferenceBarrier || (use->is_ConstraintCast() && use->Opcode() == Op_CastPP)) { alloc_worklist.append_if_missing(use); #ifdef ASSERT From rwestrel at redhat.com Tue Nov 26 16:37:33 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 26 Nov 2019 17:37:33 +0100 Subject: RFR (sh/8): Remove to wrong handlings of Shenandoah LRB in escape analysis In-Reply-To: <76643e45-ae70-5a0d-4e32-7bc7b53fd434@redhat.com> References: <76643e45-ae70-5a0d-4e32-7bc7b53fd434@redhat.com> Message-ID: <87k17mbnle.fsf@redhat.com> > Before I forget (because it is not tracked), here is the backport of a > recent fix that I did in 11. It has baked there for 2 weeks now. > > ok to push? Ok. Roland. From rkennke at redhat.com Tue Nov 26 17:18:24 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 26 Nov 2019 17:18:24 +0000 Subject: hg: shenandoah/jdk8/hotspot: [backport] Remove to wrong handlings of Shenandoah LRB in escape analysis Message-ID: <201911261718.xAQHIOGw026197@aojmv0008.oracle.com> Changeset: b9601b57b3c4 Author: rkennke Date: 2019-11-26 17:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b9601b57b3c4 [backport] Remove to wrong handlings of Shenandoah LRB in escape analysis ! src/share/vm/opto/escape.cpp From zgu at redhat.com Tue Nov 26 18:07:07 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 Nov 2019 13:07:07 -0500 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <8232be6d-1942-ab42-b72a-6f92bafd70f9@redhat.com> References: <932a10af-0f0e-067e-778d-fe853f01288c@redhat.com> <8191daa9-0dfb-99a7-8433-25e3d9378082@oracle.com> <8232be6d-1942-ab42-b72a-6f92bafd70f9@redhat.com> Message-ID: <1eb4f382-e76f-0688-df26-906b3f62c63f@redhat.com> Hi Erik, On 11/26/19 8:24 AM, Zhengyu Gu wrote: >> Here is a patch with my proposed cleanup: >> http://cr.openjdk.java.net/~eosterlund/8230765/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8230765/webrev.01_02/ >> > > Yes, this indeed a much cleaner approach. I will take your proposed > cleanup and run through submit. I took your patch. There is just one little hiccup: compiler expects intptr_t instead of int* on x86_32, the fix is straightforward. __ push(tmp); - __ movptr(tmp, bs_nm->disarmed_value_address()); + __ movptr(tmp, (intptr_t)bs_nm->disarmed_value_address()); Address disarmed_addr(tmp, 0); __ align(4); __ cmpl(disarmed_addr, 0); Full webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.02/ and patch passed submit tests. Okay to push? Thanks, -Zhengyu > > -Zhengyu > > >> Thanks, >> /Erik >> >> On 11/25/19 9:35 PM, Zhengyu Gu wrote: >>> Hi all, >>> >>> Please review this implementation of nmethod barrier for x86_32 >>> platforms. >>> >>> x86_32 implementation mirrors x86_64's. The only difference is where >>> it reads nmethod disarmed value. >>> >>> Unlike 64-bits, 32-bits platform does not have a dedicated register >>> for current thread. So that it is cheaper to read disarmed value from >>> global location than from per-thread GC data. >>> >>> Currently, only Shenandoah GC uses the implementation for its >>> concurrent class unloading. This implementation, along with >>> Shenandoah concurrent class unloading, has been baked in >>> shenandoah/jdk repo for some time now,? they are ready for integration. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ >>> >>> >>> Test: >>> ? hotspot_gc with x86_64 and x86_32 JVM on Linux >>> ? Submit test. >>> >>> Thanks, >>> >>> -Zhengyu >>> >> From erik.osterlund at oracle.com Tue Nov 26 18:43:00 2019 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Tue, 26 Nov 2019 19:43:00 +0100 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <1eb4f382-e76f-0688-df26-906b3f62c63f@redhat.com> References: <1eb4f382-e76f-0688-df26-906b3f62c63f@redhat.com> Message-ID: <13594682-4B7F-41D9-9D4B-84419BADC408@oracle.com> Hi Zhengyu, Looks good; ship it. Thanks /Erik > On 26 Nov 2019, at 19:07, Zhengyu Gu wrote: > > ?Hi Erik, > > On 11/26/19 8:24 AM, Zhengyu Gu wrote: >>> Here is a patch with my proposed cleanup: >>> http://cr.openjdk.java.net/~eosterlund/8230765/webrev.02/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~eosterlund/8230765/webrev.01_02/ >>> >> Yes, this indeed a much cleaner approach. I will take your proposed cleanup and run through submit. > > I took your patch. There is just one little hiccup: compiler expects intptr_t instead of int* on x86_32, the fix is straightforward. > > __ push(tmp); > - __ movptr(tmp, bs_nm->disarmed_value_address()); > + __ movptr(tmp, (intptr_t)bs_nm->disarmed_value_address()); > Address disarmed_addr(tmp, 0); > __ align(4); > __ cmpl(disarmed_addr, 0); > > > Full webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.02/ > > and patch passed submit tests. > > Okay to push? > > Thanks, > > -Zhengyu > > >> -Zhengyu >>> Thanks, >>> /Erik >>> >>>> On 11/25/19 9:35 PM, Zhengyu Gu wrote: >>>>> Hi all, >>>>> >>>>> Please review this implementation of nmethod barrier for x86_32 platforms. >>>>> >>>>> x86_32 implementation mirrors x86_64's. The only difference is where it reads nmethod disarmed value. >>>>> >>>>> Unlike 64-bits, 32-bits platform does not have a dedicated register for current thread. So that it is cheaper to read disarmed value from global location than from per-thread GC data. >>>>> >>>>> Currently, only Shenandoah GC uses the implementation for its concurrent class unloading. This implementation, along with Shenandoah concurrent class unloading, has been baked in shenandoah/jdk repo for some time now, they are ready for integration. >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ >>>>> >>>>> >>>>> Test: >>>>> hotspot_gc with x86_64 and x86_32 JVM on Linux >>>>> Submit test. >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>> > From zgu at redhat.com Tue Nov 26 20:46:15 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 Nov 2019 15:46:15 -0500 Subject: [14] RFR 8230765: Implement nmethod barrier for x86_32 platforms In-Reply-To: <13594682-4B7F-41D9-9D4B-84419BADC408@oracle.com> References: <1eb4f382-e76f-0688-df26-906b3f62c63f@redhat.com> <13594682-4B7F-41D9-9D4B-84419BADC408@oracle.com> Message-ID: On 11/26/19 1:43 PM, Erik ?sterlund wrote: > Hi Zhengyu, > > Looks good; ship it. Pushed. Thanks, -Zhengyu > > Thanks > /Erik > >> On 26 Nov 2019, at 19:07, Zhengyu Gu wrote: >> >> ?Hi Erik, >> >> On 11/26/19 8:24 AM, Zhengyu Gu wrote: >>>> Here is a patch with my proposed cleanup: >>>> http://cr.openjdk.java.net/~eosterlund/8230765/webrev.02/ >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~eosterlund/8230765/webrev.01_02/ >>>> >>> Yes, this indeed a much cleaner approach. I will take your proposed cleanup and run through submit. >> >> I took your patch. There is just one little hiccup: compiler expects intptr_t instead of int* on x86_32, the fix is straightforward. >> >> __ push(tmp); >> - __ movptr(tmp, bs_nm->disarmed_value_address()); >> + __ movptr(tmp, (intptr_t)bs_nm->disarmed_value_address()); >> Address disarmed_addr(tmp, 0); >> __ align(4); >> __ cmpl(disarmed_addr, 0); >> >> >> Full webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.02/ >> >> and patch passed submit tests. >> >> Okay to push? >> >> Thanks, >> >> -Zhengyu >> >> >>> -Zhengyu >>>> Thanks, >>>> /Erik >>>> >>>>> On 11/25/19 9:35 PM, Zhengyu Gu wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this implementation of nmethod barrier for x86_32 platforms. >>>>>> >>>>>> x86_32 implementation mirrors x86_64's. The only difference is where it reads nmethod disarmed value. >>>>>> >>>>>> Unlike 64-bits, 32-bits platform does not have a dedicated register for current thread. So that it is cheaper to read disarmed value from global location than from per-thread GC data. >>>>>> >>>>>> Currently, only Shenandoah GC uses the implementation for its concurrent class unloading. This implementation, along with Shenandoah concurrent class unloading, has been baked in shenandoah/jdk repo for some time now, they are ready for integration. >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230765 >>>>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8230765/webrev.01/ >>>>>> >>>>>> >>>>>> Test: >>>>>> hotspot_gc with x86_64 and x86_32 JVM on Linux >>>>>> Submit test. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>> >> > From rkennke at redhat.com Tue Nov 26 21:31:44 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 Nov 2019 22:31:44 +0100 Subject: RFR (sh/8): [backport] 8221435: Shenandoah should not mark through weak roots Message-ID: <8c680459-9126-292e-6730-9da0f5e56795@redhat.com> This backports JDK-8221435 from sh/jdk11. The sh/jdk11 change is this one: https://hg.openjdk.java.net/shenandoah/jdk11/rev/6e176ad4e069 The change is different in sh/jdk8 because there the weak roots are tangled up with strong roots in systemdictionary, and we cannot easily decouple them. The intention of the change is that weak roots only need to be processed when unloading classes, but has nothing to do with processing weak references (despite the name). The backport tries to follow that intention without doing the refactorings. http://cr.openjdk.java.net/~rkennke/JDK-8221435-sh8/webrev.00/ Testing: hotspot_gc_shenandoah Can I please get a review? Thanks, Roman From zgu at redhat.com Tue Nov 26 22:44:37 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 Nov 2019 17:44:37 -0500 Subject: RFR (sh/8): [backport] 8221435: Shenandoah should not mark through weak roots In-Reply-To: <8c680459-9126-292e-6730-9da0f5e56795@redhat.com> References: <8c680459-9126-292e-6730-9da0f5e56795@redhat.com> Message-ID: <09240437-7c92-8e43-f5b5-c108764eed23@redhat.com> Looks good to me. Thanks, -Zhengyu On 11/26/19 4:31 PM, Roman Kennke wrote: > This backports JDK-8221435 from sh/jdk11. The sh/jdk11 change is this one: > > https://hg.openjdk.java.net/shenandoah/jdk11/rev/6e176ad4e069 > > The change is different in sh/jdk8 because there the weak roots are > tangled up with strong roots in systemdictionary, and we cannot easily > decouple them. The intention of the change is that weak roots only need > to be processed when unloading classes, but has nothing to do with > processing weak references (despite the name). The backport tries to > follow that intention without doing the refactorings. > > http://cr.openjdk.java.net/~rkennke/JDK-8221435-sh8/webrev.00/ > > Testing: hotspot_gc_shenandoah > > Can I please get a review? > > Thanks, > Roman > From rkennke at redhat.com Tue Nov 26 23:00:55 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 26 Nov 2019 23:00:55 +0000 Subject: hg: shenandoah/jdk8/hotspot: [backport] 8221435: Shenandoah should not mark through weak roots Message-ID: <201911262300.xAQN0t7W001540@aojmv0008.oracle.com> Changeset: 01040e94f1e9 Author: rkennke Date: 2019-11-26 22:29 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/01040e94f1e9 [backport] 8221435: Shenandoah should not mark through weak roots ! 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/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp From gnu.andrew at redhat.com Wed Nov 27 05:31:21 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 27 Nov 2019 05:31:21 +0000 Subject: [RFR] [8u] 8u242-b01 Upstream Sync Message-ID: <646b15f6-a7bc-b5c5-a502-83fb3df9f54d@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/root/merge.changeset Changes in aarch64-shenandoah-jdk8u242-b01: - S8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp - S8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target - S8073154: NULL-pointer dereferencing in LIR_OpProfileType::print_instr - S8077707: jdk9 b58 cannot run any graphical application on Win 8 with JAWS running - S8132249: Clean up JAB debugging code - S8133951: Zero interpreter asserts in stubRoutines.cpp - S8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts - S8209835: Aarch64: elide barriers on all volatile operations - S8212071: Need to set the FreeType LCD Filter to reduce fringing. - S8230238: Add another regression test for JDK-8134739 - S8230813: Add JDK-8010500 to compiler/loopopts/superword/TestFuzzPreLoop.java bug list - S8231398: Add time tracing for gc log rotation at safepoint cleanup - S8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Main issues of note: * 8209835 is already upstream but is part of this tag. * 8073154 change to src/share/vm/c1/c1_LIR.cpp was already included in an earlier form as part of "Implement type profiling in C1." [0]. Merge conflict was resolve to use the 8u upstream version. diffstat for root b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for corba b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for jaxp b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for jaxws b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for langtools b/.hgtags | 3 b/src/share/classes/com/sun/tools/javac/jvm/Gen.java | 19 ++- b/test/tools/javac/BranchToFewerDefines.java | 111 +++++++++++++++++++ 3 files changed, 128 insertions(+), 5 deletions(-) diffstat for nashorn b/.hgtags | 3 +++ 1 file changed, 3 insertions(+) diffstat for jdk b/.hgtags | 3 b/src/share/native/sun/font/freetypeScaler.c | 3 b/src/windows/native/sun/bridge/AccessBridgeATInstance.cpp | 2 b/src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp | 2 b/src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp | 2 b/src/windows/native/sun/bridge/AccessBridgeWindowsEntryPoints.cpp | 1 b/src/windows/native/sun/bridge/JavaAccessBridge.cpp | 51 ++-------- b/src/windows/native/sun/bridge/JavaAccessBridge.h | 2 b/src/windows/native/sun/bridge/WinAccessBridge.cpp | 4 9 files changed, 26 insertions(+), 44 deletions(-) diffstat for hotspot b/.hgtags | 3 b/src/share/vm/c1/c1_LIR.cpp | 8 - b/src/share/vm/opto/loopTransform.cpp | 9 + b/src/share/vm/opto/loopnode.hpp | 1 b/src/share/vm/opto/superword.cpp | 26 +++- b/src/share/vm/runtime/safepoint.cpp | 1 b/src/share/vm/runtime/stubRoutines.cpp | 4 b/test/compiler/loopopts/TestRemoveEmptyLoop.java | 53 +++++++++ b/test/compiler/loopopts/superword/TestFuzzPreLoop.java | 65 +++++++++++ b/test/compiler/print/TestProfileReturnTypePrinting.java | 68 +++++++++++ b/test/runtime/RedefineTests/test8178870.sh | 87 +++++++++++++++ 11 files changed, 312 insertions(+), 13 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? [0] https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/050fe4f6976ab67316 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Wed Nov 27 14:17:26 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 Nov 2019 09:17:26 -0500 Subject: [14] RFR 8228720: Shenandoah: Implementation of concurrent class unloading Message-ID: <2b6697ac-68a1-a398-9030-d8517bd45c31@redhat.com> Shenandoah concurrent class unloading has been baked in shenandoah/jdk repo for quite some time, it is ready for integration into 14. The implementation is similar to ZGC's with added complexity, due to additional GC modes other than concurrent mode. E.g. degenerated GC and full GC. This patch only contains Shenandoah specific changes, the shared part has been upstreamed under JDK-8230765 to support x86_32 platforms. A few key points: 1) Available on x86_64 and x86_32 platforms with Shenandoah concurrent GC (not yet with traversal GC) 2) Concurrent class unloading is enabled by default with Shenandoah concurrent GC for every GC cycle. Class unloading can be disabled with -XX:-ClassUnloading/-XX:-ClassUnloadingWithConcurrentMark and frequency can be changed via experimental flag -XX:ShenandoahRefProcFrequency=n 3) For degenerated GC and full GC, class unloading falls back to STW. Bug: https://bugs.openjdk.java.net/browse/JDK-8228720 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228720/webrev.02 Test: hotspot_gc_shenandoah (fastdebug and release) with x86_64 and x86_32 JVM on Linux. Thanks, -Zhengyu From rkennke at redhat.com Wed Nov 27 16:15:05 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Nov 2019 17:15:05 +0100 Subject: [14] RFR 8228720: Shenandoah: Implementation of concurrent class unloading In-Reply-To: <2b6697ac-68a1-a398-9030-d8517bd45c31@redhat.com> References: <2b6697ac-68a1-a398-9030-d8517bd45c31@redhat.com> Message-ID: Hi Zhengyu, this is great work! I looked over the changeset and couldn't find anything to complain about. Thumbs up! Thanks, Roman > Shenandoah concurrent class unloading has been baked in shenandoah/jdk > repo for quite some time, it is ready for integration into 14. > > The implementation is similar to ZGC's with added complexity, due to > additional GC modes other than concurrent mode. E.g. degenerated GC and > full GC. > > This patch only contains Shenandoah specific changes, the shared part > has been upstreamed under JDK-8230765 to support x86_32 platforms. > > A few key points: > > 1) Available on x86_64 and x86_32 platforms with Shenandoah concurrent > GC (not yet with traversal GC) > > 2) Concurrent class unloading is enabled by default with Shenandoah > concurrent GC for every GC cycle. Class unloading can be disabled with > -XX:-ClassUnloading/-XX:-ClassUnloadingWithConcurrentMark and frequency > can be changed via experimental flag -XX:ShenandoahRefProcFrequency=n > > 3) For degenerated GC and full GC, class unloading falls back to STW. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228720 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228720/webrev.02 > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) with x86_64 and x86_32 > ? JVM on Linux. > > Thanks, > > -Zhengyu > From zgu at redhat.com Wed Nov 27 16:25:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 Nov 2019 11:25:43 -0500 Subject: [14] RFR 8228720: Shenandoah: Implementation of concurrent class unloading In-Reply-To: References: <2b6697ac-68a1-a398-9030-d8517bd45c31@redhat.com> Message-ID: Thanks, Roman. -Zhengyu On 11/27/19 11:15 AM, Roman Kennke wrote: > Hi Zhengyu, > > this is great work! > > I looked over the changeset and couldn't find anything to complain > about. Thumbs up! > > Thanks, > Roman > >> Shenandoah concurrent class unloading has been baked in shenandoah/jdk >> repo for quite some time, it is ready for integration into 14. >> >> The implementation is similar to ZGC's with added complexity, due to >> additional GC modes other than concurrent mode. E.g. degenerated GC and >> full GC. >> >> This patch only contains Shenandoah specific changes, the shared part >> has been upstreamed under JDK-8230765 to support x86_32 platforms. >> >> A few key points: >> >> 1) Available on x86_64 and x86_32 platforms with Shenandoah concurrent >> GC (not yet with traversal GC) >> >> 2) Concurrent class unloading is enabled by default with Shenandoah >> concurrent GC for every GC cycle. Class unloading can be disabled with >> -XX:-ClassUnloading/-XX:-ClassUnloadingWithConcurrentMark and frequency >> can be changed via experimental flag -XX:ShenandoahRefProcFrequency=n >> >> 3) For degenerated GC and full GC, class unloading falls back to STW. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228720 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228720/webrev.02 >> >> Test: >> ? hotspot_gc_shenandoah (fastdebug and release) with x86_64 and x86_32 >> ? JVM on Linux. >> >> Thanks, >> >> -Zhengyu >> > From rkennke at redhat.com Thu Nov 28 12:14:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 28 Nov 2019 13:14:13 +0100 Subject: Merge jdk-14+25 Message-ID: We haven't merged from upstream for a while. Let's do it now. Since concurrent-class-unloading is now upstream, this brings the diff to zero. List of changes: http://cr.openjdk.java.net/~rkennke/upstream-jdk14-merge-2019-11-18/changesets.txt There've been a few merge conflicts, which have been resolved by always picking the incoming option. I also checked the diff to jdk-14+25 and removed some whitespaces here and there to ensure it's completely clean. Testing: hotspot_gc_shenandoah (x86_64 and x86_32) Ok? Roman