<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com> Message-ID: Hi, Can I get a review? Updated to current shenandoah/jdk head. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.02/ Reran: tier3_gc_shenandoah (fastdebug + release), all with -XX:+UseStringDeduplication. Thanks, -Zhengyu On 06/29/2018 07:23 AM, Zhengyu Gu wrote: > Hi, > > This is updated Shenandoah string deduplication based on official > upstream shared implementation. > > Based on Roman's comment, I moved worker id into > ShenandoahThreadLocalData, instead of using language feature. > > Webrev: > http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.01/ > > Test: > > ? tier3_gc_shenandoah, all tests with -XX:+UseStringDeduplication > ? (release + fastdebug) > > ? specjvm with -XX:+UseStringDeduplication > > > Thanks, > > -Zhengyu > > > On 06/02/2018 04:39 AM, Roman Kennke wrote: >> >> Is that a thread-local variable ?: >> >> +? static __thread uint _worker_id; >> >> Is there no better way to achieve the same? E.g. we don't want to put it >> into ShenandoahThreadLocalData or such? The worker_id seems small enough >> to actually fit into a byte. Maybe we have a byte-field left in ShTLD >> without requiring to blow up its word-size? >> >> Other than that, looks good. >> >> Thank you!! >> Roman >> >>> Shenandoah only webrev: >>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/sh-only/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 05/29/2018 03:54 PM, Zhengyu Gu wrote: >>>> Hi, >>>> >>>> This refactoring is based on upstream JDK-8203641, which is still >>>> under review >>>> (http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032565.html). >>>> >>>> >>>> >>>> We initially borrowed G1's string deduplication implementation, but we >>>> diverged at one point, due to we may need to enqueue candidates inside >>>> write barrier. It is not the case anymore. >>>> >>>> Once JDK-8203641 upstreamed, we can share dedup table and thread >>>> implementation, only need to plugin in our queue implementation. >>>> >>>> It looks like StringDedupTable is another candidate to be replaced by >>>> ConcurrentHashTable, we should be able to benefit from it too. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/webrev.00/ >>>> >>>> >>>> >>>> >>>> Test: >>>> ??? hotspot_gc_shenandoah (fastdebug and release) >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >> >> From shade at redhat.com Mon Jul 2 18:01:15 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 2 Jul 2018 20:01:15 +0200 Subject: RFR: Application pacing precision fixes Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/pacing-precision/webrev.01/ This resolves a few important issues in pacing implementation. *) Evac pacing used live data as the guidance for cset evacuation progress. Since there is no allocation allowed in cset, we can just make use of SH::used, and get more smooth pacing. Smoothness is improved because most regions in cset are 100% used, but liveness deviates very much in single-digit percents. At that point, bitmap scans (looking for marked objects) have substantial costs, so liveness becomes bad proxy for GC progress. We also want to report progress before yielding. *) Update-refs pacing used live_data to report progress, *but* the pacing baseline was SH::used! Which means this phase had the potential to underestimate the GC progress. Then, update-ref-ing the regions that are allocating means it could overestimate the GC progress, because it would report recent allocations too as "progress". It is unknown which way this balance tips. New code takes "used at update-refs start" for each region as the GC progress guidance. This also makes update-refs pacing similar to evac pacing. *) Mark pacing is all over the place. Assuming the entire heap is live makes pacing very aggressive, especially in cases where heap is mostly dead. This is the only place where we have to use live-data as the proxy for GC progress. But to get the idea about the relative GC progress, we have to know how much live data there is in the heap. I tried a few things (e.g. manual thresholds, etc.), but recording history seems more reliable. The same thing applies to Traversal. This whole thing significantly improve response times with long GC cycles. Testing: tier3_gc_shenandoah, benchmarks Thanks, -Aleksey From shade at redhat.com Mon Jul 2 18:15:00 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 2 Jul 2018 20:15:00 +0200 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: References:

<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com> Message-ID: On 07/02/2018 07:51 PM, Zhengyu Gu wrote: > Can I get a review? I can do it tomorrow, sorry for the delay. -Aleksey From zgu at redhat.com Mon Jul 2 18:15:50 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 2 Jul 2018 14:15:50 -0400 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: References:

<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com>

Message-ID: <88880298-7ed2-d6db-8ea4-6d344099d9e9@redhat.com> On 07/02/2018 02:15 PM, Aleksey Shipilev wrote: > On 07/02/2018 07:51 PM, Zhengyu Gu wrote: >> Can I get a review? > > I can do it tomorrow, sorry for the delay. No problem. Thanks, -Zhengyu > > -Aleksey > From rkennke at redhat.com Mon Jul 2 18:32:58 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 2 Jul 2018 20:32:58 +0200 Subject: RFR: Application pacing precision fixes In-Reply-To: References: Message-ID: <2f62661a-aa89-2fc2-055a-8df4fc02bfd7@redhat.com> Looks good. Thanks! Roman > http://cr.openjdk.java.net/~shade/shenandoah/pacing-precision/webrev.01/ > > This resolves a few important issues in pacing implementation. > > *) Evac pacing used live data as the guidance for cset evacuation progress. Since there is no > allocation allowed in cset, we can just make use of SH::used, and get more smooth pacing. Smoothness > is improved because most regions in cset are 100% used, but liveness deviates very much in > single-digit percents. At that point, bitmap scans (looking for marked objects) have substantial > costs, so liveness becomes bad proxy for GC progress. We also want to report progress before yielding. > > *) Update-refs pacing used live_data to report progress, *but* the pacing baseline was SH::used! > Which means this phase had the potential to underestimate the GC progress. Then, update-ref-ing the > regions that are allocating means it could overestimate the GC progress, because it would report > recent allocations too as "progress". It is unknown which way this balance tips. New code takes > "used at update-refs start" for each region as the GC progress guidance. This also makes update-refs > pacing similar to evac pacing. > > *) Mark pacing is all over the place. Assuming the entire heap is live makes pacing very > aggressive, especially in cases where heap is mostly dead. This is the only place where we have to > use live-data as the proxy for GC progress. But to get the idea about the relative GC progress, we > have to know how much live data there is in the heap. I tried a few things (e.g. manual thresholds, > etc.), but recording history seems more reliable. The same thing applies to Traversal. > > This whole thing significantly improve response times with long GC cycles. > > Testing: tier3_gc_shenandoah, benchmarks > > Thanks, > -Aleksey > From rkennke at redhat.com Mon Jul 2 20:44:47 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 2 Jul 2018 22:44:47 +0200 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: References:

<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com> Message-ID: <2ba1181a-ce7a-1f5b-43f6-39f21279f00b@redhat.com> Is it really necessary to use global locks? Is there no instance that can 'carry' the lock? I guess it's not a Shenandoah specific lock though, right? IOW, similar issue as with SATB locks..? Thread-local is not a language feature, yet. Coming with c++11. I believe it's ok to put in ShenandoahThreadLocalData as long as we don't need to extend its size. We should have some room left because of ZGC :-) Should we ever switch to C++11 we'd use real thread_local though, I guess. I trust you with the actual dedup code, there is not much I can review there that you don't know better. The rest of patch looks ok to me. Thank you for doing this! Roman > Hi, > > Can I get a review? > > Updated to current shenandoah/jdk head. > > Webrev: > http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.02/ > > > Reran: tier3_gc_shenandoah (fastdebug + release), all with > -XX:+UseStringDeduplication. > > Thanks, > > -Zhengyu > > On 06/29/2018 07:23 AM, Zhengyu Gu wrote: >> Hi, >> >> This is updated Shenandoah string deduplication based on official >> upstream shared implementation. >> >> Based on Roman's comment, I moved worker id into >> ShenandoahThreadLocalData, instead of using language feature. >> >> Webrev: >> http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.01/ >> >> Test: >> >> ?? tier3_gc_shenandoah, all tests with -XX:+UseStringDeduplication >> ?? (release + fastdebug) >> >> ?? specjvm with -XX:+UseStringDeduplication >> >> >> Thanks, >> >> -Zhengyu >> >> >> On 06/02/2018 04:39 AM, Roman Kennke wrote: >>> >>> Is that a thread-local variable ?: >>> >>> +? static __thread uint _worker_id; >>> >>> Is there no better way to achieve the same? E.g. we don't want to put it >>> into ShenandoahThreadLocalData or such? The worker_id seems small enough >>> to actually fit into a byte. Maybe we have a byte-field left in ShTLD >>> without requiring to blow up its word-size? >>> >>> Other than that, looks good. >>> >>> Thank you!! >>> Roman >>> >>>> Shenandoah only webrev: >>>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/sh-only/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> On 05/29/2018 03:54 PM, Zhengyu Gu wrote: >>>>> Hi, >>>>> >>>>> This refactoring is based on upstream JDK-8203641, which is still >>>>> under review >>>>> (http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032565.html). >>>>> >>>>> >>>>> >>>>> We initially borrowed G1's string deduplication implementation, but we >>>>> diverged at one point, due to we may need to enqueue candidates inside >>>>> write barrier. It is not the case anymore. >>>>> >>>>> Once JDK-8203641 upstreamed, we can share dedup table and thread >>>>> implementation, only need to plugin in our queue implementation. >>>>> >>>>> It looks like StringDedupTable is another candidate to be replaced by >>>>> ConcurrentHashTable, we should be able to benefit from it too. >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/webrev.00/ >>>>> >>>>> >>>>> >>>>> >>>>> Test: >>>>> ??? hotspot_gc_shenandoah (fastdebug and release) >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>> >>> From zgu at redhat.com Mon Jul 2 21:02:38 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 2 Jul 2018 17:02:38 -0400 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: <2ba1181a-ce7a-1f5b-43f6-39f21279f00b@redhat.com> References:

<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com> <2ba1181a-ce7a-1f5b-43f6-39f21279f00b@redhat.com> Message-ID: On 07/02/2018 04:44 PM, Roman Kennke wrote: > Is it really necessary to use global locks? Is there no instance that > can 'carry' the lock? I guess it's not a Shenandoah specific lock > though, right? IOW, similar issue as with SATB locks..? I assume you are talking about StringDedupQueue_lock and StringDedupTable_lock, right? We adapted upstream's implementation, so yes, it is similar to SATB locks, we do need them too. > > > Thread-local is not a language feature, yet. Coming with c++11. I > believe it's ok to put in ShenandoahThreadLocalData as long as we don't > need to extend its size. We should have some room left because of ZGC > :-) Should we ever switch to C++11 we'd use real thread_local though, I > guess. > Kind of wonder where are we, in term of C++ version. ZGC already uses it. I asked Thomas Schatzl what's they takes on thread-local, he did not answer :-) > I trust you with the actual dedup code, there is not much I can review > there that you don't know better. > > The rest of patch looks ok to me. > Thanks, -Zhengyu > Thank you for doing this! > Roman > > >> Hi, >> >> Can I get a review? >> >> Updated to current shenandoah/jdk head. >> >> Webrev: >> http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.02/ >> >> >> Reran: tier3_gc_shenandoah (fastdebug + release), all with >> -XX:+UseStringDeduplication. >> >> Thanks, >> >> -Zhengyu >> >> On 06/29/2018 07:23 AM, Zhengyu Gu wrote: >>> Hi, >>> >>> This is updated Shenandoah string deduplication based on official >>> upstream shared implementation. >>> >>> Based on Roman's comment, I moved worker id into >>> ShenandoahThreadLocalData, instead of using language feature. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.01/ >>> >>> Test: >>> >>> ?? tier3_gc_shenandoah, all tests with -XX:+UseStringDeduplication >>> ?? (release + fastdebug) >>> >>> ?? specjvm with -XX:+UseStringDeduplication >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> On 06/02/2018 04:39 AM, Roman Kennke wrote: >>>> >>>> Is that a thread-local variable ?: >>>> >>>> +? static __thread uint _worker_id; >>>> >>>> Is there no better way to achieve the same? E.g. we don't want to put it >>>> into ShenandoahThreadLocalData or such? The worker_id seems small enough >>>> to actually fit into a byte. Maybe we have a byte-field left in ShTLD >>>> without requiring to blow up its word-size? >>>> >>>> Other than that, looks good. >>>> >>>> Thank you!! >>>> Roman >>>> >>>>> Shenandoah only webrev: >>>>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/sh-only/webrev.00/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> On 05/29/2018 03:54 PM, Zhengyu Gu wrote: >>>>>> Hi, >>>>>> >>>>>> This refactoring is based on upstream JDK-8203641, which is still >>>>>> under review >>>>>> (http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032565.html). >>>>>> >>>>>> >>>>>> >>>>>> We initially borrowed G1's string deduplication implementation, but we >>>>>> diverged at one point, due to we may need to enqueue candidates inside >>>>>> write barrier. It is not the case anymore. >>>>>> >>>>>> Once JDK-8203641 upstreamed, we can share dedup table and thread >>>>>> implementation, only need to plugin in our queue implementation. >>>>>> >>>>>> It looks like StringDedupTable is another candidate to be replaced by >>>>>> ConcurrentHashTable, we should be able to benefit from it too. >>>>>> >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~zgu/shenandoah/dedup_shared_refactor/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Test: >>>>>> ??? hotspot_gc_shenandoah (fastdebug and release) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>> >>>> > > From rkennke at redhat.com Mon Jul 2 21:16:13 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 2 Jul 2018 23:16:13 +0200 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: References:

<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com> <2ba1181a-ce7a-1f5b-43f6-39f21279f00b@redhat.com> Message-ID: <8250496b-0121-0cb7-b14a-5f58abc8c32c@redhat.com> Am 02.07.2018 um 23:02 schrieb Zhengyu Gu: > > > On 07/02/2018 04:44 PM, Roman Kennke wrote: >> Is it really necessary to use global locks? Is there no instance that >> can 'carry' the lock? I guess it's not a Shenandoah specific lock >> though, right? IOW, similar issue as with SATB locks..? > > I assume you are talking about StringDedupQueue_lock and > StringDedupTable_lock, right? > > We adapted upstream's implementation, so yes, it is similar to SATB > locks, we do need them too. ok. >> Thread-local is not a language feature, yet. Coming with c++11. I >> believe it's ok to put in ShenandoahThreadLocalData as long as we don't >> need to extend its size. We should have some room left because of ZGC >> :-) Should we ever switch to C++11 we'd use real thread_local though, I >> guess. >> > > Kind of wonder where are we, in term of C++ version. C++98: $ grep -R "\-std" make/* make/autoconf/flags-cflags.m4: CXXSTD_CXXFLAG="-std=gnu++98" I think this should be one of the next major OpenJDK goals to go straight to c++17 or so. > ZGC already uses > it. I asked Thomas Schatzl what's they takes on thread-local, he did not > answer :-) Hmm, no. ZGC uses: static __thread which is, a GCC-ism: https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html C++ (>=11) thread-locals use the thread_local keyword: https://en.cppreference.com/w/cpp/language/storage_duration Cheers, Roman From zgu at redhat.com Mon Jul 2 23:03:22 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 2 Jul 2018 19:03:22 -0400 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: <8250496b-0121-0cb7-b14a-5f58abc8c32c@redhat.com> References:

Message-ID: <5cdaa300-6db1-2e9d-9856-14127cc1131c@redhat.com> shenandoahBarrierSetC1.hpp L#116 G1PreBarrierStub -> ShenandoahWriteBarrierStub -Zhengyu On 07/03/2018 06:56 AM, Aleksey Shipilev wrote: > On 07/03/2018 12:50 PM, Roman Kennke wrote: >> We currently use a dedicated C1 LIR instruction to implement the >> Shenandoah write barrier. This is not easily supported by the current >> BarrierSetC1 interface. What works better is to use CodeStub (like all >> other GC's barriers), so let's turn Shenandoah's write barrier (back) to >> using CodeStubs. This removes a whole lot of upstream changes and >> confines Shenandoah barrier stuff to gc/shenandoah. >> >> http://cr.openjdk.java.net/~rkennke/c1-shenandoah-codestubs/webrev.01/ > > *) Comment is wrong in ShenandoahBarrierSetC1::write_barrier_impl: > > 224 // Read the marking-in-progress flag. > > Otherwise looks good! > > -Aleksey > From rkennke at redhat.com Tue Jul 3 12:19:38 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 03 Jul 2018 14:19:38 +0200 Subject: RFR: Make C1 write-barrier use a stub instead of dedicated instruction In-Reply-To: <5cdaa300-6db1-2e9d-9856-14127cc1131c@redhat.com> References:

<6f43d01a-b835-96af-fde7-f43ea3cd79af@redhat.com> <0eb8e341-b2b2-5214-67eb-96ab1d408944@redhat.com> <52bbfb23-3953-d9e9-e1d3-356b0068724c@redhat.com> Message-ID: <600057e1-f055-79a3-22ba-08b78e183ae5@redhat.com> Thanks for the review. On 07/03/2018 11:53 AM, Aleksey Shipilev wrote: > On 07/02/2018 07:51 PM, Zhengyu Gu wrote: >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.02/ > > Nice to see another upstream diff ripout! > > *) Should we split out ShenandoahWorkerSession into a separate changeset for backporting? Split into two changesets: Worker session: http://cr.openjdk.java.net/~zgu/shenandoah/worker_id/webrev.00/ String dedup: http://cr.openjdk.java.net/~zgu/shenandoah/shared_stringdedup/webrev.03/ > > *) In shenandoahHeap.cpp, this does not seem to be needed: > 2196 ShenandoahHeap* heap = ShenandoahHeap::heap(); Fixed. > > *) Use locals: > > 105 static inline uint worker_id() { > 106 Thread* thr = Thread::current(); > 107 assert(ShenandoahThreadLocalData::worker_id(thr) != > ShenandoahThreadLocalData::INVALID_WORKER_ID, "Worker session has not been created"); > 108 return ShenandoahThreadLocalData::worker_id(thr); > 109 } > > ... > > static inline uint worker_id() { > Thread* thr = Thread::current(); > id = ShenandoahThreadLocalData::worker_id(thr); > assert(id != ShenandoahThreadLocalData::INVALID_WORKER_ID, "Worker session has not been created"); > return id; > } Fixed. Test: Reran tier3_gc_shenandoah. Thanks, -Zhengyu > > Thanks, > -Aleksey > From shade at redhat.com Tue Jul 3 17:52:52 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 3 Jul 2018 19:52:52 +0200 Subject: RFR: Shenandoah String Dedup refactoring In-Reply-To: <600057e1-f055-79a3-22ba-08b78e183ae5@redhat.com> References:

Message-ID: <2e6021e3-4d1b-cac9-da81-89679151e596@redhat.com> On 07/06/2018 10:13 AM, Simone Bordet wrote: >> Binary builds: >> https://builds.shipilev.net/openjdk-shenandoah-jdk11/ > > If I interpret the file name correctly, they seem to be based on > jdk11-b4, while latest is jdk11-b21? > I ask because jdk11-b8+ contains important NIO changes that I would > like to try with Shenandoah. These are internal build numbers, having no relation to repo tags. If you look into repo history, then you will notice we have jdk-11+21 tag inside [1]. Which means NIO fixes are there and you can try the build now. > If b4 refers to Shenandoah, would be it be possible to know also the > jdk11-bXX version they are based on, if that makes sense? That would make sense, sure! Now I only have to figure out to bend the build system to include tags. Thanks, -Aleksey [1] http://hg.openjdk.java.net/shenandoah/jdk11/tags From rkennke at redhat.com Fri Jul 6 08:28:40 2018 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 6 Jul 2018 10:28:40 +0200 Subject: Shenandoah JDK 11 In-Reply-To: <2e6021e3-4d1b-cac9-da81-89679151e596@redhat.com> References:

Message-ID: Am 10.07.2018 um 11:01 schrieb Aleksey Shipilev: > On 07/10/2018 10:59 AM, Roman Kennke wrote: >> Am 10.07.2018 um 10:56 schrieb Aleksey Shipilev: >>> http://cr.openjdk.java.net/~shade/shenandoah/sbs-forwarded-check/webrev.01/ >>> >>> This fixes the bug in write_barrier_impl in x86_64: we should check either for 0, or for >>> HAS_FORWARDED when deciding to omit the read barrier. C1 write barrier tests HAS_FORWARDED and it >>> seems most efficient when coalescing is not available. So, the rest homogenizes the check shape >>> across architectures. >>> >>> Testing: tier3_gc_shenandoah (x86_64), build (aarch64) >>> >>> Thanks, >>> -Aleksey >>> >> >> Can you hold it back until I pushed the consolidation? > > I think it is cleaner to go the other way around: we first push this thing that fixes the barriers, > because it is also backportable, then we rebase and push consolidation, that is less backportable. > But either way, I can redo the patch during backports... Ok, then please push that change, and I'll re-do the consolidating patch. Roman From ashipile at redhat.com Tue Jul 10 09:05:20 2018 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 10 Jul 2018 09:05:20 +0000 Subject: hg: shenandoah/jdk: Assembler write barriers should consistently check for forwarded objects Message-ID: <201807100905.w6A95KkA025207@aojmv0008.oracle.com> Changeset: 8e66b8530b44 Author: shade Date: 2018-07-10 11:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8e66b8530b44 Assembler write barriers should consistently check for forwarded objects ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp From shade at redhat.com Tue Jul 10 09:05:41 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Jul 2018 11:05:41 +0200 Subject: RFR: Assembler write barriers should consistently check for forwarded objects In-Reply-To: References: <7b62c0a0-a71c-0d8d-ed63-5fde98a30456@redhat.com>

Message-ID: <7ec0cf4f-094a-e5a6-d424-5ad4afb99e87@redhat.com> On 07/10/2018 11:03 AM, Roman Kennke wrote: > Am 10.07.2018 um 11:01 schrieb Aleksey Shipilev: >> On 07/10/2018 10:59 AM, Roman Kennke wrote: >>> Am 10.07.2018 um 10:56 schrieb Aleksey Shipilev: >>>> http://cr.openjdk.java.net/~shade/shenandoah/sbs-forwarded-check/webrev.01/ >>>> >>>> This fixes the bug in write_barrier_impl in x86_64: we should check either for 0, or for >>>> HAS_FORWARDED when deciding to omit the read barrier. C1 write barrier tests HAS_FORWARDED and it >>>> seems most efficient when coalescing is not available. So, the rest homogenizes the check shape >>>> across architectures. >>>> >>>> Testing: tier3_gc_shenandoah (x86_64), build (aarch64) >>>> >>>> Thanks, >>>> -Aleksey >>>> >>> >>> Can you hold it back until I pushed the consolidation? >> >> I think it is cleaner to go the other way around: we first push this thing that fixes the barriers, >> because it is also backportable, then we rebase and push consolidation, that is less backportable. >> But either way, I can redo the patch during backports... > > Ok, then please push that change, and I'll re-do the consolidating patch. Pushed. -Aleksey From rkennke at redhat.com Tue Jul 10 09:23:25 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 10 Jul 2018 11:23:25 +0200 Subject: RFR: Re-add Shenandoah TLAB allocation in aarch64 assembly Message-ID: This went missing during one of the recent TLAB modularization refactorings. http://cr.openjdk.java.net/~rkennke/aarch64-tlab/webrev.00/ Ok? Roman From rkennke at redhat.com Tue Jul 10 09:28:30 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 10 Jul 2018 11:28:30 +0200 Subject: RFR: Re-add Shenandoah TLAB allocation in aarch64 assembly In-Reply-To: References: Message-ID: Am 10.07.2018 um 11:23 schrieb Roman Kennke: > This went missing during one of the recent TLAB modularization refactorings. > > http://cr.openjdk.java.net/~rkennke/aarch64-tlab/webrev.00/ > > Ok? > > Roman > Sorry, little mistake, please review this one: http://cr.openjdk.java.net/~rkennke/aarch64-tlab/webrev.02/ From shade at redhat.com Tue Jul 10 09:48:29 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Jul 2018 11:48:29 +0200 Subject: RFR: Re-add Shenandoah TLAB allocation in aarch64 assembly In-Reply-To: References:

Message-ID: <329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> On 07/12/2018 05:05 PM, Roman Kennke wrote: > Am 12.07.2018 um 15:51 schrieb Roland Westrelin: >> >> http://cr.openjdk.java.net/~roland/shenandoah/aarch64-membars-elision/webrev.02/ >> >> This fixes membar elision on aarch64 with shenandoah. Thanks to Andrew >> Dinn for verifying the change and fixing the traversal gc case. >> >> Roland. >> > > > The patch looks good. > > I verified that it builds + passes tests. > > I'll check the predicates in x86. They should be equivalent. If there are predicate changes that make sense on their own, they should be pushed as separate changesets, so they arrive to backports. -Aleksey From rkennke at redhat.com Thu Jul 12 15:11:07 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 12 Jul 2018 17:11:07 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: <329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> Message-ID: <97de9d23-ddbc-5246-df36-446f81da0f25@redhat.com> Am 12.07.2018 um 17:09 schrieb Aleksey Shipilev: > On 07/12/2018 05:05 PM, Roman Kennke wrote: >> Am 12.07.2018 um 15:51 schrieb Roland Westrelin: >>> >>> http://cr.openjdk.java.net/~roland/shenandoah/aarch64-membars-elision/webrev.02/ >>> >>> This fixes membar elision on aarch64 with shenandoah. Thanks to Andrew >>> Dinn for verifying the change and fixing the traversal gc case. >>> >>> Roland. >>> >> >> >> The patch looks good. >> >> I verified that it builds + passes tests. >> >> I'll check the predicates in x86. They should be equivalent. > > If there are predicate changes that make sense on their own, they should be pushed as separate > changesets, so they arrive to backports. That is what I meant. Please push this to sh/jdk. I'll check the rest separately. Roman From zgu at redhat.com Thu Jul 12 15:15:17 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Jul 2018 11:15:17 -0400 Subject: RFR: Add task termination and enhanced task queue state tracking In-Reply-To: <627e6f7d-c26e-161d-9721-2383333f2764@redhat.com> References: <7a73acf2-a041-6b80-0be7-b870ffd1dde4@redhat.com> <627e6f7d-c26e-161d-9721-2383333f2764@redhat.com> Message-ID: <7b7f0ba0-1d6e-9669-6cfb-bba0145fe9b2@redhat.com> Updated: http://cr.openjdk.java.net/~zgu/shenandoah/termination_tracking/webrev.01/ -XX:+ShenandoahTerminationTrace [info][gc,stats] Finish Queues = 0.01 s (a = 181 us) (n = 36) [info][gc,stats] Termination = 0.00 s (a = 43 us) (n = 36) [info][gc,stats] Concurrent Marking = 3.79 s (a = 105316 us) (n = 36) [info][gc,stats] Termination = 0.11 s (a = 2940 us) (n = 36) -XX:-ShenandoahTerminationTrace [info][gc,stats] Finish Queues = 0.01 s (a = 154 us) (n = 37) [info][gc,stats] Concurrent Marking = 3.99 s (a = 107877 us) (n = 37) Thanks, -Zhengyu On 07/12/2018 10:05 AM, Aleksey Shipilev wrote: > On 07/12/2018 03:39 PM, Zhengyu Gu wrote: >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/termination_tracking/webrev.00/ > > The patch looks good. > > How often do threads request termination? Are we sure this tracking does not introduce its own > latencies, e.g. due timer calls and contention on counters themselves? Maybe we can guard it with > the diagnostic ShenandoahTerminationTrace flag in ShenandoahTerminationTimings to be able to dissect? > > Thanks, > -Aleksey > > From shade at redhat.com Thu Jul 12 15:18:03 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Jul 2018 17:18:03 +0200 Subject: RFR: Add task termination and enhanced task queue state tracking In-Reply-To: <7b7f0ba0-1d6e-9669-6cfb-bba0145fe9b2@redhat.com> References: <7a73acf2-a041-6b80-0be7-b870ffd1dde4@redhat.com> <627e6f7d-c26e-161d-9721-2383333f2764@redhat.com> <7b7f0ba0-1d6e-9669-6cfb-bba0145fe9b2@redhat.com> Message-ID: <4ed7c7ef-255f-01dd-3987-3e1035984e26@redhat.com> On 07/12/2018 05:15 PM, Zhengyu Gu wrote: > Updated: > > http://cr.openjdk.java.net/~zgu/shenandoah/termination_tracking/webrev.01/ Okay, good. -Aleksey From zgu at redhat.com Thu Jul 12 15:19:24 2018 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 12 Jul 2018 15:19:24 +0000 Subject: hg: shenandoah/jdk: Add task termination and enhanced task queue state tracking Message-ID: <201807121519.w6CFJO9p012831@aojmv0008.oracle.com> Changeset: fc5f751ca97f Author: zgu Date: 2018-07-12 11:19 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/fc5f751ca97f Add task termination and enhanced task queue state tracking ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp From rkennke at redhat.com Thu Jul 12 15:32:38 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 12 Jul 2018 17:32:38 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: <329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> Message-ID: <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com> Am 12.07.2018 um 17:09 schrieb Aleksey Shipilev: > On 07/12/2018 05:05 PM, Roman Kennke wrote: >> Am 12.07.2018 um 15:51 schrieb Roland Westrelin: >>> >>> http://cr.openjdk.java.net/~roland/shenandoah/aarch64-membars-elision/webrev.02/ >>> >>> This fixes membar elision on aarch64 with shenandoah. Thanks to Andrew >>> Dinn for verifying the change and fixing the traversal gc case. >>> >>> Roland. >>> >> >> >> The patch looks good. >> >> I verified that it builds + passes tests. >> >> I'll check the predicates in x86. They should be equivalent. > > If there are predicate changes that make sense on their own, they should be pushed as separate > changesets, so they arrive to backports. > > -Aleksey > Oh wait, I just got this from a test: # Internal Error (/home/rkennke/src/shenandoah-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2873), pid=27969, tid=28271 # guarantee(mbar != NULL) failed: CAS not embedded in normal graph! Hmmmmmm. From rwestrel at redhat.com Thu Jul 12 16:11:11 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 12 Jul 2018 18:11:11 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com> References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com> Message-ID: > Oh wait, I just got this from a test: > > # Internal Error > (/home/rkennke/src/shenandoah-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2873), > pid=27969, tid=28271 > # guarantee(mbar != NULL) failed: CAS not embedded in normal graph! What test it it? Do you have a replay file? Is it with traversal enabled? Roland. From shade at redhat.com Thu Jul 12 16:33:12 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Jul 2018 18:33:12 +0200 Subject: RFR: Report actual free size in non-verbose FreeSet status Message-ID: <5933ec03-4804-a8be-50b7-ef5279e90154@redhat.com> It misleadingly prints "Free:" for the entire capacity, which only makes sense when no allocations happened yet. Easy fix: diff -r 55965025794c src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Thu Jul 12 12:04:55 2018 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Thu Jul 12 12:19:26 2018 +0200 @@ -456,7 +456,7 @@ void ShenandoahFreeSet::log_status() { log_info(gc, ergo)("Free: " SIZE_FORMAT "M, Regions: " SIZE_FORMAT " mutator, " SIZE_FORMAT " collector", - capacity() / M, mutator_count(), collector_count()); + available() / M, mutator_count(), collector_count()); } void ShenandoahFreeSet::log_status_verbose() { Testing: eyeballing logs Thanks, -Aleksey From shade at redhat.com Thu Jul 12 16:34:45 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Jul 2018 18:34:45 +0200 Subject: RFR: Pacer for evacuation should print "Avail" to capture discounting Message-ID: <54dead6a-8cb4-98e8-c964-3f147071acdd@redhat.com> Pacer for Evacuation prints "Free" for the value that is actually free minus cset, because it discounts cset for future evacs. Makes the log misleading, better to say "Avail": diff -r 2ce3f06bf1ff src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp Thu Jul 12 12:19:26 2018 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp Thu Jul 12 12:20:42 2018 +0200 @@ -100,7 +100,7 @@ restart_with(non_taxable, tax); - log_info(gc, ergo)("Pacer for Evacuation. Used CSet: " SIZE_FORMAT "M, Free: " SIZE_FORMAT + log_info(gc, ergo)("Pacer for Evacuation. Used CSet: " SIZE_FORMAT "M, Avail: " SIZE_FORMAT "M, Non-Taxable: " SIZE_FORMAT "M, Alloc Tax Rate: %.1fx", used / M, free / M, non_taxable / M, tax); } Testing: eyeballing logs -Aleksey From shade at redhat.com Thu Jul 12 16:51:40 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Jul 2018 18:51:40 +0200 Subject: RFR: Elastic TLABs for Shenandoah Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/elastic-tlabs/webrev.01/ Upstream has this nice new feature for G1: https://bugs.openjdk.java.net/browse/JDK-8191471 This implements the handling on Shenandoah side, replacing our TLAB trimming hack. It is actually three changesets in one: a) Refactor allocation path to accept ShenandoahAllocRequest tuple This pushes the needed data through the allocation path down to the actual TLAB alloc. b) Elastic TLABs support for Shenandoah This is a small change in FreeSet that adjusts TLAB allocations if current region cannot satisfy the full TLAB size. It finally allows to ditch the TLAB trimming, and allow allocation path to request region-sized TLAB without ill effects. Which alleviates the contention on allocation lock, because we can now have 8x less calls to TLAB refill slowpath. c) Pacer should account actual size for elastic TLABs This is the leftover change to give pacer the claimed tokens back if trimmed TLAB was allocated. Some caveats in tracking that we are adding tokens back to the same phase budget needed to be resolved. Testing: tier3_gc_shenadnoah, benchmarks Thanks, -Aleksey From rkennke at redhat.com Thu Jul 12 17:02:48 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 12 Jul 2018 19:02:48 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com> Message-ID: On 07/13/2018 04:33 PM, Roland Westrelin wrote: > >> Oh wait, I just got this from a test: >> >> # Internal Error >> (/home/rkennke/src/shenandoah-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2873), >> pid=27969, tid=28271 >> # guarantee(mbar != NULL) failed: CAS not embedded in normal graph! > > With this test we're running with: > > -XX:+ShenandoahSATBBarrier -XX:+ShenandoahWriteBarrier -XX:+ShenandoahReadBarrier -XX:+ShenandoahStoreValEnqueueBarrier > > so we have a write barrier, an enqueue barrier and a satb barrier above > the CAS. Why does it make sense to run with options that are not usually > enabled together? The test is used to verify that we do not emit barriers when particular types of barriers are disabled: there are asserts all over runtime, C1 and C2 code to test these. Over time, it started to be the test to make sure that arguments/heuristics code verifies and drops the incompatible combination of flags. -Aleksey From rwestrel at redhat.com Fri Jul 13 14:40:23 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 13 Jul 2018 16:40:23 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>

Message-ID: > The test is used to verify that we do not emit barriers when particular types of barriers are > disabled: there are asserts all over runtime, C1 and C2 code to test these. Over time, it started to > be the test to make sure that arguments/heuristics code verifies and drops the incompatible > combination of flags. Can we simply skip barrier elision in case of a strange combination of options? It's a pain to fix that code. Roland. From rkennke at redhat.com Fri Jul 13 14:40:56 2018 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 13 Jul 2018 16:40:56 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>

Message-ID: <54d02a47-37d2-93d2-46d4-d120408a7c43@redhat.com> Am 13.07.2018 um 16:37 schrieb Aleksey Shipilev: > On 07/13/2018 04:33 PM, Roland Westrelin wrote: >> >>> Oh wait, I just got this from a test: >>> >>> # Internal Error >>> (/home/rkennke/src/shenandoah-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2873), >>> pid=27969, tid=28271 >>> # guarantee(mbar != NULL) failed: CAS not embedded in normal graph! >> >> With this test we're running with: >> >> -XX:+ShenandoahSATBBarrier -XX:+ShenandoahWriteBarrier -XX:+ShenandoahReadBarrier -XX:+ShenandoahStoreValEnqueueBarrier >> >> so we have a write barrier, an enqueue barrier and a satb barrier above >> the CAS. Why does it make sense to run with options that are not usually >> enabled together? > > The test is used to verify that we do not emit barriers when particular types of barriers are > disabled: there are asserts all over runtime, C1 and C2 code to test these. Over time, it started to > be the test to make sure that arguments/heuristics code verifies and drops the incompatible > combination of flags. > > -Aleksey > > Yes, but enqueue-barriers and satb-barriers are mutally exclusive. There is no point in enabling both. In fact, we should check+verify that this is not even attempted. Roman From shade at redhat.com Fri Jul 13 14:42:20 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 13 Jul 2018 16:42:20 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>

<54d02a47-37d2-93d2-46d4-d120408a7c43@redhat.com> Message-ID: > Yes, but enqueue-barriers and satb-barriers are mutally exclusive. There > is no point in enabling both. In fact, we should check+verify that this > is not even attempted. Can I push the change as it is then? Roland. From shade at redhat.com Mon Jul 16 09:24:52 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Jul 2018 11:24:52 +0200 Subject: RFR: Add task termination and enhanced task queue state tracking In-Reply-To: <4ed7c7ef-255f-01dd-3987-3e1035984e26@redhat.com> References: <7a73acf2-a041-6b80-0be7-b870ffd1dde4@redhat.com> <627e6f7d-c26e-161d-9721-2383333f2764@redhat.com> <7b7f0ba0-1d6e-9669-6cfb-bba0145fe9b2@redhat.com> <4ed7c7ef-255f-01dd-3987-3e1035984e26@redhat.com> Message-ID: <59f98782-2b99-6ac2-764a-d5bcdbf3660b@redhat.com> On 07/12/2018 05:18 PM, Aleksey Shipilev wrote: > On 07/12/2018 05:15 PM, Zhengyu Gu wrote: >> Updated: >> >> http://cr.openjdk.java.net/~zgu/shenandoah/termination_tracking/webrev.01/ > > Okay, good. Actually, I now have a follow-up question, why this assert was deleted? shenandoahConcurrentMark.cpp: 499 assert(task_queues()->is_empty(), "Should be empty"); Please reinstate if that removal was erroneous. -Aleksey From rkennke at redhat.com Mon Jul 16 09:43:16 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 16 Jul 2018 11:43:16 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>

<54d02a47-37d2-93d2-46d4-d120408a7c43@redhat.com> Message-ID: <14b68517-107b-775c-3a70-b45f54cccf9a@redhat.com> Am 16.07.2018 um 10:26 schrieb Roland Westrelin: > >> Yes, but enqueue-barriers and satb-barriers are mutally exclusive. There >> is no point in enabling both. In fact, we should check+verify that this >> is not even attempted. > > Can I push the change as it is then? Have you posted a fix for the failing test? Or do you want us to take care of it after you pushed? Roman From rwestrel at redhat.com Mon Jul 16 10:09:23 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 16 Jul 2018 12:09:23 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: <14b68517-107b-775c-3a70-b45f54cccf9a@redhat.com> References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>

<54d02a47-37d2-93d2-46d4-d120408a7c43@redhat.com> <14b68517-107b-775c-3a70-b45f54cccf9a@redhat.com> Message-ID: > Have you posted a fix for the failing test? Or do you want us to take > care of it after you pushed? I haven't. Not sure how you want this fixed (fix the test? disallow combination of flags?) so it seems best if you handle it. Roland. From rkennke at redhat.com Mon Jul 16 10:19:45 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 16 Jul 2018 12:19:45 +0200 Subject: RFR: fix aarch64 membar elision with shenandoah In-Reply-To: References:

<329f56ed-29b9-50f9-c3ec-b5d273dd943e@redhat.com> <7b4a889b-fa80-773b-831c-8b68f1469565@redhat.com>