From rwestrel at redhat.com Wed Mar 1 15:53:59 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 01 Mar 2017 16:53:59 +0100 Subject: Loop strip mining to decreases safepoint poll frequency In-Reply-To: References: <55fd5826-51e7-c061-cb4a-e4ddc2e63484@redhat.com> Message-ID: > -UseCLS: no safepoints, no mining > -UseCLS LSM=0: no safepoints, no mining > -UseCLS LSM>=1: illegal? > +UseCLS: safepoints + mining > +UseCLS LSM=0: illegal? > +UseCLS LSM=1: safepoints, but no mining > +UseCLS LSM>=1: safepoints + mining Something like this, then? diff --git a/src/share/vm/runtime/arguments.cpp b/src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp +++ b/src/share/vm/runtime/arguments.cpp @@ -2630,8 +2630,16 @@ } FLAG_SET_CMDLINE(bool, PostLoopMultiversioning, false); } - if (UseCountedLoopSafepoints) { + if (UseCountedLoopSafepoints && LoopStripMiningIter == 0) { + if (!FLAG_IS_DEFAULT(UseCountedLoopSafepoints) && !FLAG_IS_DEFAULT(LoopStripMiningIter)) { + warning("When counted loop safepoints are enabled, LoopStripMiningIter must be at least 1 (a safepoint every 1 iteration): setting it to 1"); + } LoopStripMiningIter = 1; + } else if (!UseCountedLoopSafepoints && LoopStripMiningIter > 0) { + if (!FLAG_IS_DEFAULT(UseCountedLoopSafepoints) && !FLAG_IS_DEFAULT(LoopStripMiningIter)) { + warning("Disabling counted safepoints implies no loop strip mining: setting LoopStripMiningIter to 0"); + } + LoopStripMiningIter = 0; } #endif return status; Roland. From rkennke at redhat.com Wed Mar 1 19:37:35 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 1 Mar 2017 20:37:35 +0100 Subject: RFR: Implement barriers to maintain connection matrix Message-ID: .. as subject says. The connection matrix is implemented in its own class. The stuff is not optimized yet. Christine's connection matrix code is still there, but no longer operational. -XX:+UseShenandoahMatrix turns on matrix bookkeeping. -XX:+PrintShenandoahMatrix prints the matrix at end of marking. -XX:+VerifyShenandoahMatrix verifies the matrix at end of marking. For now, it needs -XX:ArrayCopyLoadStoreMaxElem=0 to turn of an arraycopy optimization that requires additional barriers too. It should not have measurable impact when not turned on. Ok? http://cr.openjdk.java.net/~rkennke/thematrix/webrev.00/ Roman From shade at redhat.com Thu Mar 2 09:28:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 2 Mar 2017 10:28:50 +0100 Subject: Loop strip mining to decreases safepoint poll frequency In-Reply-To: References: <55fd5826-51e7-c061-cb4a-e4ddc2e63484@redhat.com> Message-ID: <26cb5291-fa66-96f6-ca7b-501ceb955fe2@redhat.com> On 03/01/2017 04:53 PM, Roland Westrelin wrote: > >> -UseCLS: no safepoints, no mining >> -UseCLS LSM=0: no safepoints, no mining >> -UseCLS LSM>=1: illegal? >> +UseCLS: safepoints + mining >> +UseCLS LSM=0: illegal? >> +UseCLS LSM=1: safepoints, but no mining >> +UseCLS LSM>=1: safepoints + mining > > Something like this, then? > > diff --git a/src/share/vm/runtime/arguments.cpp b/src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp > +++ b/src/share/vm/runtime/arguments.cpp > @@ -2630,8 +2630,16 @@ > } > FLAG_SET_CMDLINE(bool, PostLoopMultiversioning, false); > } > - if (UseCountedLoopSafepoints) { > + if (UseCountedLoopSafepoints && LoopStripMiningIter == 0) { > + if (!FLAG_IS_DEFAULT(UseCountedLoopSafepoints) && !FLAG_IS_DEFAULT(LoopStripMiningIter)) { > + warning("When counted loop safepoints are enabled, LoopStripMiningIter must be at least 1 (a safepoint every 1 iteration): setting it to 1"); > + } > LoopStripMiningIter = 1; > + } else if (!UseCountedLoopSafepoints && LoopStripMiningIter > 0) { > + if (!FLAG_IS_DEFAULT(UseCountedLoopSafepoints) && !FLAG_IS_DEFAULT(LoopStripMiningIter)) { > + warning("Disabling counted safepoints implies no loop strip mining: setting LoopStripMiningIter to 0"); > + } > + LoopStripMiningIter = 0; > } > #endif > return status; Yes, this sounds right. Thanks, -Aleksey From shade at redhat.com Thu Mar 2 10:13:31 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 2 Mar 2017 11:13:31 +0100 Subject: RFR: Implement barriers to maintain connection matrix In-Reply-To: References: Message-ID: <79e2c4a1-5e82-687f-b97c-e68dc3cc2e00@redhat.com> On 03/01/2017 08:37 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/thematrix/webrev.00/ *) c1_LIRGenerator.cpp: T_LONG does not sound right here. C1 should have something to deal with native pointer width? 1683 LIR_Opr tmp4 = new_register(T_LONG); 1684 __ move(LIR_OprFact::intptrConst((intptr_t) matrix->matrix_addr()), tmp4); *) referenceProcessor.cpp: That trailing boolean arg is obscure: 901 oop retest; 902 if (UseShenandoahGC && UseShenandoahMatrix) { 903 retest = oopDesc::atomic_compare_exchange_oop(next_discovered, discovered_addr, 904 NULL, true); 905 } else { 906 retest = oopDesc::atomic_compare_exchange_oop(next_discovered, discovered_addr, 907 NULL); 908 } Is this just: oop retest = oopDesc::atomic_compare_exchange_oop(next_discovered, discovered_addr, (UseShenandoahGC && UseShenandoahMatrix)); *) shenandoahConcurrentMark.cpp, ShenandoahRefProcTaskProxy.work: Am I blind, or the newly added branch under UseShenandoahMatrix is the same as the branch on "else" path? *) shenandoahHeap.cpp, ShenandoahHeap::prepare_for_concurrent_evacuation() Bad indent. *) shenandoahOopClosures.hpp Confused why ShenandoahMarkRefsMatrixClosure uses CONCURRENT while ShenandoahMarkRefsMetadataMatrixClosure uses NONE. These two should use the same, no? *) macro.cpp Put assert(UseShenandoahGC) here: 314 } else { 315 C->shenandoah_eliminate_matrix_update(p2x, &_igvn); Otherwise looks good. Thanks, -Aleksey From shade at redhat.com Fri Mar 3 12:23:04 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 13:23:04 +0100 Subject: RFR (S): [9+8u] Min region size should be 256K to allow small heaps Message-ID: <268de3f5-ad83-f377-590c-2d61d069b84e@redhat.com> Hi, Turns out, some JDK tool launchers set -Xms8M. Shenandoah fails cryptically then: Error occurred during initialization of VM Invalid -XX:ShenandoahMinRegionSize option While those tools configs are the actual culprit, we might want to bite the bullet and afford those smaller heaps. And turns out, we supposed to! Because the failure is due to requesting 10 regions, with SHR::MIN_REGION_SIZE being 256K. But that ShenandoahMinRegionSize default is 1M, oops. I suggest we change ShenandoahMinRegionSize to match MIN_REGION_SIZE: http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-match/webrev.01/ I don't want to depend on ShenandoahHeapRegion in *globals.hpp. Tests should cover future discrepancies. The patch applies to 8u with some fuzz, and I will push it there simultaneously with 9. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Fri Mar 3 12:26:04 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Mar 2017 13:26:04 +0100 Subject: RFR (S): [9+8u] Min region size should be 256K to allow small heaps In-Reply-To: <268de3f5-ad83-f377-590c-2d61d069b84e@redhat.com> References: <268de3f5-ad83-f377-590c-2d61d069b84e@redhat.com> Message-ID: <1a2a263a-7571-5c30-811b-b9e816c44981@redhat.com> Am 03.03.2017 um 13:23 schrieb Aleksey Shipilev: > Hi, > > Turns out, some JDK tool launchers set -Xms8M. Shenandoah fails cryptically then: > > Error occurred during initialization of VM > Invalid -XX:ShenandoahMinRegionSize option > > While those tools configs are the actual culprit, we might want to bite the > bullet and afford those smaller heaps. And turns out, we supposed to! Because > the failure is due to requesting 10 regions, with SHR::MIN_REGION_SIZE being > 256K. But that ShenandoahMinRegionSize default is 1M, oops. I suggest we change > ShenandoahMinRegionSize to match MIN_REGION_SIZE: > http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-match/webrev.01/ > > I don't want to depend on ShenandoahHeapRegion in *globals.hpp. Tests should > cover future discrepancies. > > The patch applies to 8u with some fuzz, and I will push it there simultaneously > with 9. > > Testing: hotspot_gc_shenandoah Ok! Roman From ashipile at redhat.com Fri Mar 3 12:29:44 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 12:29:44 +0000 Subject: hg: shenandoah/jdk9/hotspot: ShenandoahMinRegionSize should be 256K to allow small heaps. Message-ID: <201703031229.v23CTiSQ021330@aojmv0008.oracle.com> Changeset: 710d02eae915 Author: shade Date: 2017-03-03 13:28 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/710d02eae915 ShenandoahMinRegionSize should be 256K to allow small heaps. ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/TestRegionSizeArgs.java From ashipile at redhat.com Fri Mar 3 12:29:47 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 12:29:47 +0000 Subject: hg: shenandoah/jdk8u/hotspot: ShenandoahMinRegionSize should be 256K to allow small heaps. Message-ID: <201703031229.v23CTljQ021342@aojmv0008.oracle.com> Changeset: fa1071cc5aee Author: shade Date: 2017-03-03 13:29 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/fa1071cc5aee ShenandoahMinRegionSize should be 256K to allow small heaps. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/TestRegionSizeArgs.java From shade at redhat.com Fri Mar 3 12:30:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 13:30:25 +0100 Subject: RFR (S): [9+8u] Min region size should be 256K to allow small heaps In-Reply-To: <1a2a263a-7571-5c30-811b-b9e816c44981@redhat.com> References: <268de3f5-ad83-f377-590c-2d61d069b84e@redhat.com> <1a2a263a-7571-5c30-811b-b9e816c44981@redhat.com> Message-ID: <0abceb0c-2207-3d7f-0bae-78bbeb41c619@redhat.com> On 03/03/2017 01:26 PM, Roman Kennke wrote: > Am 03.03.2017 um 13:23 schrieb Aleksey Shipilev: >> Hi, >> >> Turns out, some JDK tool launchers set -Xms8M. Shenandoah fails cryptically then: >> >> Error occurred during initialization of VM >> Invalid -XX:ShenandoahMinRegionSize option >> >> While those tools configs are the actual culprit, we might want to bite the >> bullet and afford those smaller heaps. And turns out, we supposed to! Because >> the failure is due to requesting 10 regions, with SHR::MIN_REGION_SIZE being >> 256K. But that ShenandoahMinRegionSize default is 1M, oops. I suggest we change >> ShenandoahMinRegionSize to match MIN_REGION_SIZE: >> http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-match/webrev.01/ >> >> I don't want to depend on ShenandoahHeapRegion in *globals.hpp. Tests should >> cover future discrepancies. >> >> The patch applies to 8u with some fuzz, and I will push it there simultaneously >> with 9. >> >> Testing: hotspot_gc_shenandoah > > Ok! > Pushed: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/710d02eae915 http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/fa1071cc5aee -Aleksey From rwestrel at redhat.com Fri Mar 3 14:05:27 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 03 Mar 2017 14:05:27 +0000 Subject: hg: shenandoah/jdk9/hotspot: loop strip mining Message-ID: <201703031405.v23E5RoU016973@aojmv0008.oracle.com> Changeset: f8a19195242b Author: roland Date: 2017-03-03 13:52 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/f8a19195242b loop strip mining ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/opaquenode.cpp ! src/share/vm/opto/opaquenode.hpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/runtime/arguments.cpp From rwestrel at redhat.com Fri Mar 3 14:07:09 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 03 Mar 2017 15:07:09 +0100 Subject: Loop strip mining to decreases safepoint poll frequency In-Reply-To: References: <55fd5826-51e7-c061-cb4a-e4ddc2e63484@redhat.com> Message-ID: > Something like this, then? Actually || instead of && in the patch below when checking whether flags have default value. Anyway, it's pushed. Roland. > > diff --git a/src/share/vm/runtime/arguments.cpp b/src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp > +++ b/src/share/vm/runtime/arguments.cpp > @@ -2630,8 +2630,16 @@ > } > FLAG_SET_CMDLINE(bool, PostLoopMultiversioning, false); > } > - if (UseCountedLoopSafepoints) { > + if (UseCountedLoopSafepoints && LoopStripMiningIter == 0) { > + if (!FLAG_IS_DEFAULT(UseCountedLoopSafepoints) && !FLAG_IS_DEFAULT(LoopStripMiningIter)) { > + warning("When counted loop safepoints are enabled, LoopStripMiningIter must be at least 1 (a safepoint every 1 iteration): setting it to 1"); > + } > LoopStripMiningIter = 1; > + } else if (!UseCountedLoopSafepoints && LoopStripMiningIter > 0) { > + if (!FLAG_IS_DEFAULT(UseCountedLoopSafepoints) && !FLAG_IS_DEFAULT(LoopStripMiningIter)) { > + warning("Disabling counted safepoints implies no loop strip mining: setting LoopStripMiningIter to 0"); > + } > + LoopStripMiningIter = 0; > } > #endif > return status; > > Roland. From rwestrel at redhat.com Fri Mar 3 14:56:35 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 03 Mar 2017 15:56:35 +0100 Subject: Make a copy of strip mined loops with small number of iterations from profiling Message-ID: http://cr.openjdk.java.net/~roland/shenandoah/stripminingshort/webrev.00/ Here is a somewhat experimental patch: when profiling indicates a strip mined loop doesn't run for many iterations on average, a copy of the loop is made without the outer loop. A test is compiled in the code to switch between the short version and the full blow strip mined loop based on the number of actual iterations. Roland. From rwestrel at redhat.com Fri Mar 3 15:28:05 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 03 Mar 2017 16:28:05 +0100 Subject: profile based loop predication Message-ID: http://cr.openjdk.java.net/~roland/shenandoah/profilepredicate/webrev.00/ Here is another somewhat experimental change. We found that sometimes, shenandoah barriers would be kept in inner loops because they depend on null checks that themselves are not hoisted. The reason for that is that loop predication only looks at predicates (such as null checks) that are executed in every iterations of the loop. I supposed the rational is that we don't want a rarely executed predicate to be moved out of loop and becomes more frequently executed. This change uses profiling to estimate whether moving the predicate out of loop is expected to pay off: it looks at every paths in the loop body for a predicate, evaluates the frequency of the path and uses an the number of iterations in the loop (again evaluated from profiling data) to decide whether hoisting a predicate is safe. This is applied to the 2 inner most loops of a loop nest. Roland. From shade at redhat.com Fri Mar 3 15:32:51 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 16:32:51 +0100 Subject: Make a copy of strip mined loops with small number of iterations from profiling In-Reply-To: References: Message-ID: <02944297-a182-5b8d-ad23-2b7a5fd60865@redhat.com> On 03/03/2017 03:56 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/shenandoah/stripminingshort/webrev.00/ Okay. Introduce the const variable (right at the method) for this, please? Some wording about how it is chosen would be nice, even if it says "this is a blind guess": LoopStripMiningIter / 10 Thanks, -Aleksey From rwestrel at redhat.com Fri Mar 3 15:54:43 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 03 Mar 2017 16:54:43 +0100 Subject: Make a copy of strip mined loops with small number of iterations from profiling In-Reply-To: <02944297-a182-5b8d-ad23-2b7a5fd60865@redhat.com> References: <02944297-a182-5b8d-ad23-2b7a5fd60865@redhat.com> Message-ID: > Okay. Introduce the const variable (right at the method) for this, please? Some > wording about how it is chosen would be nice, even if it says "this is a blind > guess": > LoopStripMiningIter / 10 What about this (yes that magic constant was already used elsewhere)? Roland. diff --git a/src/share/vm/opto/c2_globals.hpp b/src/share/vm/opto/c2_globals.hpp --- a/src/share/vm/opto/c2_globals.hpp +++ b/src/share/vm/opto/c2_globals.hpp @@ -741,6 +741,10 @@ "Number of iterations in strip mined loop") \ range(0, max_juint) \ \ + product(intx, LoopStripMiningIterShortLoop, 0, \ + "Loop with fewer iterations are not strip mined") \ + range(0, max_juint) \ + \ product(bool, LoopStripMiningCopyShort, true, \ "Make a copy of loop with no strip mining when profiling shows " \ "they execute few iterations") \ diff --git a/src/share/vm/opto/loopTransform.cpp b/src/share/vm/opto/loopTransform.cpp --- a/src/share/vm/opto/loopTransform.cpp +++ b/src/share/vm/opto/loopTransform.cpp @@ -2792,7 +2792,7 @@ cl->is_strip_mined() && !cl->is_strip_mined_short_cloned() && !cl->has_exact_trip_count() && - cl->profile_trip_cnt() < LoopStripMiningIter / 10) { + cl->profile_trip_cnt() < LoopStripMiningIterShortLoop) { int nodes_left = phase->C->max_node_limit() - phase->C->live_nodes(); if ((int)(2 * _body.size()) <= nodes_left) { int stride = cl->stride_con(); diff --git a/src/share/vm/opto/opaquenode.cpp b/src/share/vm/opto/opaquenode.cpp --- a/src/share/vm/opto/opaquenode.cpp +++ b/src/share/vm/opto/opaquenode.cpp @@ -97,10 +97,11 @@ int stride = inner_cl->stride_con(); jlong scaled_iters_long = ((jlong)LoopStripMiningIter) * ABS(stride); int scaled_iters = (int)scaled_iters_long; + int short_scaled_iters = LoopStripMiningIterShortLoop* ABS(stride); const TypeInt* inner_iv_t = phase->type(inner_iv_phi)->is_int(); jlong iter_estimate = (jlong)inner_iv_t->_hi - (jlong)inner_iv_t->_lo; assert(iter_estimate > 0, "broken"); - if ((jlong)scaled_iters != scaled_iters_long || iter_estimate <= scaled_iters_long / 10) { + if ((jlong)scaled_iters != scaled_iters_long || iter_estimate <= short_scaled_iters) { // Remove outer loop and safepoint (too few iterations) Node* outer_sfpt = le->in(0); assert(outer_sfpt->Opcode() == Op_SafePoint, "broken outer loop"); diff --git a/src/share/vm/runtime/arguments.cpp b/src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp +++ b/src/share/vm/runtime/arguments.cpp @@ -2641,6 +2641,10 @@ } LoopStripMiningIter = 0; } + if (FLAG_IS_DEFAULT(LoopStripMiningIterShortLoop)) { + // blind guess + LoopStripMiningIterShortLoop = LoopStripMiningIter / 10; + } #endif return status; } From shade at redhat.com Fri Mar 3 15:55:56 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 16:55:56 +0100 Subject: Make a copy of strip mined loops with small number of iterations from profiling In-Reply-To: References: <02944297-a182-5b8d-ad23-2b7a5fd60865@redhat.com> Message-ID: <53a70e37-1c2c-f4b6-4173-60ddd1bdef6e@redhat.com> On 03/03/2017 04:54 PM, Roland Westrelin wrote: >> Okay. Introduce the const variable (right at the method) for this, please? Some >> wording about how it is chosen would be nice, even if it says "this is a blind >> guess": >> LoopStripMiningIter / 10 > > What about this (yes that magic constant was already used elsewhere)? Even better! -Aleksey From shade at redhat.com Fri Mar 3 16:15:04 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 17:15:04 +0100 Subject: RFR (XS): Heap alignment should agree with ShenandoahMaxRegionSize Message-ID: <7bf3d79d-624d-be48-5ad4-7d159660645c@redhat.com> Hi, Tried to use 1G regions with 4T heap, and fastdebug failed with # assert((((size_t) _first_region_bottom) & (ShenandoahHeapRegion::RegionSizeBytes - 1)) == 0) failed: misaligned heap: 0x00007b05f4000000 This is because CollectedHeap::conservative_heap_alignment() returns 32M, not the value overridden from the command line! And, we poll the value from G1, not from our own ShenandoahHeapRegion! Remarkably, in 8u, we return ShenandoahMaxRegionSize. This is the fix for 9: http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-heap-align/webrev.01/ Moved both constants close to verification code that their only use. Will commit a part of this patch to 8u that does the same. Testing: hotspot_gc_shenandoah (9/8u), 1G regions with 4T heap startup :) Thanks, -Aleksey From rkennke at redhat.com Fri Mar 3 16:54:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Mar 2017 17:54:13 +0100 Subject: RFR (XS): Heap alignment should agree with ShenandoahMaxRegionSize In-Reply-To: <7bf3d79d-624d-be48-5ad4-7d159660645c@redhat.com> References: <7bf3d79d-624d-be48-5ad4-7d159660645c@redhat.com> Message-ID: <916a0c7a-0e2b-9766-21ac-f4f8648497c3@redhat.com> Am 03.03.2017 um 17:15 schrieb Aleksey Shipilev: > Hi, > > Tried to use 1G regions with 4T heap, and fastdebug failed with > > # assert((((size_t) _first_region_bottom) & > (ShenandoahHeapRegion::RegionSizeBytes - 1)) == 0) failed: misaligned heap: > 0x00007b05f4000000 > > This is because CollectedHeap::conservative_heap_alignment() returns 32M, not > the value overridden from the command line! And, we poll the value from G1, not > from our own ShenandoahHeapRegion! Remarkably, in 8u, we return > ShenandoahMaxRegionSize. > > This is the fix for 9: > http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-heap-align/webrev.01/ > > Moved both constants close to verification code that their only use. Will commit > a part of this patch to 8u that does the same. > > Testing: hotspot_gc_shenandoah (9/8u), 1G regions with 4T heap startup :) > > Thanks, > -Aleksey > Yes! From ashipile at redhat.com Fri Mar 3 16:55:13 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 16:55:13 +0000 Subject: hg: shenandoah/jdk9/hotspot: Heap alignment should agree with ShenandoahMaxRegionSize. Message-ID: <201703031655.v23GtDm5027130@aojmv0008.oracle.com> Changeset: 56ab58d5aa55 Author: shade Date: 2017-03-03 17:23 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/56ab58d5aa55 Heap alignment should agree with ShenandoahMaxRegionSize. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp From ashipile at redhat.com Fri Mar 3 16:55:36 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 16:55:36 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Heap alignment should agree with ShenandoahMaxRegionSize. Message-ID: <201703031655.v23GtauC027207@aojmv0008.oracle.com> Changeset: 0d2836a803cb Author: shade Date: 2017-03-03 17:55 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0d2836a803cb Heap alignment should agree with ShenandoahMaxRegionSize. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp From shade at redhat.com Fri Mar 3 17:30:40 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 18:30:40 +0100 Subject: RFR (S): [9+8u] Stack overflow in choose_collection_set on high region count Message-ID: <1fde9ca7-15ac-94dc-ccc3-cc78a3a9f773@redhat.com> Hi, Again, running on large machine with lots of regions, you will see this: # SIGSEGV (0xb) at pc=0x00007f3d9ff76235, pid=26678, tid=26928 # # JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build 9-internal+0-adhoc.root.shenandoah-jdk9) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 9-internal+0-adhoc.root.shenandoah-jdk9, mixed mode, tiered, Shenandoah gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x140c235] ShenandoahHeuristics::choose_collection_set(ShenandoahCollectionSet*, int*)+0x145 This is because "candidates" array in choose_collection_set is automatically allocated on stack, and for large number of regions, it overflows! At best, we will crash with SEGV, but may also silently corrupt something. My fault for not allocating it on heap from the start. Fix: http://cr.openjdk.java.net/~shade/shenandoah/cset-stackoverflow/webrev.01/ Going to push to both 9 and 8u. Testing: hotspot_gc_shenandoah (9/8u) + failing configuration on large machine Thanks, -Aleksey From rkennke at redhat.com Fri Mar 3 18:25:49 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Mar 2017 13:25:49 -0500 (EST) Subject: RFR (S): [9+8u] Stack overflow in choose_collection_set on high region count Message-ID: <315370525.31310432.1488565549606.JavaMail.zimbra@zmail25.collab.prod.int.phx2.redhat.com> Looks OK. Does it hurt to alloc once with max-regions in constructor, and dealloc in destructor? RomanAm 03.03.2017 6:31 nachm. schrieb Aleksey Shipilev : > > Hi, > > Again, running on large machine with lots of regions, you will see this: > > #? SIGSEGV (0xb) at pc=0x00007f3d9ff76235, pid=26678, tid=26928 > # > # JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build > 9-internal+0-adhoc.root.shenandoah-jdk9) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug > 9-internal+0-adhoc.root.shenandoah-jdk9, mixed mode, tiered, Shenandoah gc, > linux-amd64) > # Problematic frame: > # V? [libjvm.so+0x140c235] > ShenandoahHeuristics::choose_collection_set(ShenandoahCollectionSet*, int*)+0x145 > > This is because "candidates" array in choose_collection_set is automatically > allocated on stack, and for large number of regions, it overflows! At best, we > will crash with SEGV, but may also silently corrupt something. My fault for not > allocating it on heap from the start. > > Fix: > ? http://cr.openjdk.java.net/~shade/shenandoah/cset-stackoverflow/webrev.01/ > > Going to push to both 9 and 8u. > > Testing: hotspot_gc_shenandoah (9/8u) + failing configuration on large machine > > > Thanks, > -Aleksey > From shade at redhat.com Fri Mar 3 18:28:35 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 19:28:35 +0100 Subject: RFR (S): [9+8u] Stack overflow in choose_collection_set on high region count In-Reply-To: <315370525.31310432.1488565549606.JavaMail.zimbra@zmail25.collab.prod.int.phx2.redhat.com> References: <315370525.31310432.1488565549606.JavaMail.zimbra@zmail25.collab.prod.int.phx2.redhat.com> Message-ID: <3c936c6b-bc52-d777-b619-585f3570cdc5@redhat.com> On 03/03/2017 07:25 PM, Roman Kennke wrote: > Looks OK. > > Does it hurt to alloc once with max-regions in constructor, and dealloc in destructor? It does hurt interface-wise: need to pass maxRegions during policy/heuristics init, which needs to extend interface, and sets us up for circularities. Thanks, -Aleksey From ashipile at redhat.com Fri Mar 3 18:39:44 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 18:39:44 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Stack overflow in choose_collection_set on high region count. Message-ID: <201703031839.v23Idi4f021828@aojmv0008.oracle.com> Changeset: 7ae4b2f2740a Author: shade Date: 2017-03-03 19:39 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/7ae4b2f2740a Stack overflow in choose_collection_set on high region count. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp From ashipile at redhat.com Fri Mar 3 18:39:51 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 18:39:51 +0000 Subject: hg: shenandoah/jdk9/hotspot: Stack overflow in choose_collection_set on high region count. Message-ID: <201703031839.v23Idp9L021899@aojmv0008.oracle.com> Changeset: 8c42940a4bdc Author: shade Date: 2017-03-03 19:39 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/8c42940a4bdc Stack overflow in choose_collection_set on high region count. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From shade at redhat.com Fri Mar 3 19:30:02 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 20:30:02 +0100 Subject: RFR (XS) [9+8u] Explicit ShenandoahHeapRegionSize should be checked against min/max Message-ID: The flip side of heap alignment depending on ShenandoahMaxRegionSize is that we cannot allow explicit ShenandoahHeapRegionSize to cross it. It is never checked if explicit. Fix: http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-forceHRS/webrev.01/ Testing: hotspot_gc_shenandoah (9/8u) Thanks, -Aleksey From rkennke at redhat.com Fri Mar 3 21:01:50 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Mar 2017 22:01:50 +0100 Subject: RFR (XS) [9+8u] Explicit ShenandoahHeapRegionSize should be checked against min/max In-Reply-To: References: Message-ID: <1ebca83f-9690-d05d-c592-be0e053f0f5d@redhat.com> Am 03.03.2017 um 20:30 schrieb Aleksey Shipilev: > The flip side of heap alignment depending on ShenandoahMaxRegionSize is that we > cannot allow explicit ShenandoahHeapRegionSize to cross it. It is never checked > if explicit. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-forceHRS/webrev.01/ > > Testing: hotspot_gc_shenandoah (9/8u) Ok! Roman From ashipile at redhat.com Fri Mar 3 21:04:28 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 21:04:28 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Explicit ShenandoahHeapRegionSize should be checked against min/max. Message-ID: <201703032104.v23L4SCk026420@aojmv0008.oracle.com> Changeset: bb9f14a2b4ce Author: shade Date: 2017-03-03 22:03 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/bb9f14a2b4ce Explicit ShenandoahHeapRegionSize should be checked against min/max. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! test/gc/shenandoah/TestRegionSizeArgs.java From ashipile at redhat.com Fri Mar 3 21:04:46 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 03 Mar 2017 21:04:46 +0000 Subject: hg: shenandoah/jdk9/hotspot: Explicit ShenandoahHeapRegionSize should be checked against min/max. Message-ID: <201703032104.v23L4knn026644@aojmv0008.oracle.com> Changeset: 9d143b6aa466 Author: shade Date: 2017-03-03 22:04 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/9d143b6aa466 Explicit ShenandoahHeapRegionSize should be checked against min/max. ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! test/gc/shenandoah/TestRegionSizeArgs.java From rkennke at redhat.com Sat Mar 4 17:07:32 2017 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 4 Mar 2017 18:07:32 +0100 Subject: Fix issue with OOM-during-evac Message-ID: <8b53f6a3-d989-5ffe-cd38-ed4611a96f03@redhat.com> When we run OOM during the initial evacuation (at the final-mark pause), we (can) have a problem: - GC thread 1 attempts to evacuate object A at root x and fails (no GCLAB left and no memory left), leaving x pointing to A. - GC thread 2 attempts to evacuate object A at root y and succeeds (still got some GCLAB left), and updates y to point to A'. This leaves us with x pointing to A, even though we have a valid A'. This is very verboten and must not happen! The solution is to check for cancelled_concgc() after initial-evac (after all GC threads are done), and doing a fixup-refs-pass over the evacuation roots if we have run OOM. This also adds a check after initial evac that all init-evac roots are now pointing to an object without forwardee (from-space or to-space). It also moves some closures around to be accessible where we need them. http://cr.openjdk.java.net/~rkennke/fixoom-during-init-evac/webrev.00/ Ok to push? Roman From shade at redhat.com Mon Mar 6 09:16:33 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Mar 2017 10:16:33 +0100 Subject: Fix issue with OOM-during-evac In-Reply-To: <8b53f6a3-d989-5ffe-cd38-ed4611a96f03@redhat.com> References: <8b53f6a3-d989-5ffe-cd38-ed4611a96f03@redhat.com> Message-ID: <94a12986-4378-3216-b603-6e3fff32bf56@redhat.com> On 03/04/2017 06:07 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/fixoom-during-init-evac/webrev.00/ Ok. -Aleksey From roman at kennke.org Mon Mar 6 14:09:25 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 06 Mar 2017 14:09:25 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix issue with OOM-during-evac. Message-ID: <201703061409.v26E9PXv000331@aojmv0008.oracle.com> Changeset: be8380e0a309 Author: rkennke Date: 2017-03-06 15:03 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/be8380e0a309 Fix issue with OOM-during-evac. ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp From roman at kennke.org Mon Mar 6 14:24:25 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 06 Mar 2017 14:24:25 +0000 Subject: hg: shenandoah/jdk9/hotspot: Added #ifdef ASSERT around debug-only code to fix release build. Message-ID: <201703061424.v26EOP4Q003812@aojmv0008.oracle.com> Changeset: f260381335f7 Author: rkennke Date: 2017-03-06 15:23 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/f260381335f7 Added #ifdef ASSERT around debug-only code to fix release build. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp From roman at kennke.org Mon Mar 6 14:27:08 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 06 Mar 2017 14:27:08 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix issue with OOM-during-evac. Message-ID: <201703061427.v26ER80L004324@aojmv0008.oracle.com> Changeset: 45922d1a0798 Author: rkennke Date: 2017-03-06 15:03 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/45922d1a0798 Fix issue with OOM-during-evac. ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp From zgu at redhat.com Mon Mar 6 14:58:51 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 6 Mar 2017 09:58:51 -0500 Subject: Java Thread migration Message-ID: <40902c14-c4dc-024e-1a72-b14733091e5d@redhat.com> I ran a round of SPECjbb2015 tests on to-gc1, with/without NUMA auto-balancing with different GC options. The result is quite interesting: NUMA auto-balancing apparently hurts Shenandoah and increases thread migration in general. Result: http://cr.openjdk.java.net/~zgu/shenandoah/thread-migrations.html Thanks, -Zhengyu From rwestrel at redhat.com Mon Mar 6 16:07:16 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Mon, 06 Mar 2017 16:07:16 +0000 Subject: hg: shenandoah/jdk9/hotspot: Make a copy of strip mined loops with small number of iterations from profiling Message-ID: <201703061607.v26G7Ge7029599@aojmv0008.oracle.com> Changeset: 51b7a8439e80 Author: roland Date: 2017-03-03 15:40 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/51b7a8439e80 Make a copy of strip mined loops with small number of iterations from profiling ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp From rwestrel at redhat.com Mon Mar 6 16:16:39 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Mon, 06 Mar 2017 16:16:39 +0000 Subject: hg: shenandoah/jdk9/hotspot: profile based loop predication Message-ID: <201703061616.v26GGdPA001901@aojmv0008.oracle.com> Changeset: 17133d203788 Author: roland Date: 2017-03-06 15:24 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/17133d203788 profile based loop predication ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/opaquenode.cpp ! src/share/vm/runtime/arguments.cpp From rkennke at redhat.com Tue Mar 7 10:47:30 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Mar 2017 11:47:30 +0100 Subject: RFR (XS): Fix DerivedPointerTable handling when scanning roots twice in init-evac phase Message-ID: <43ff2c18-6c34-eaa9-5fc0-b33c0b5c95ae@redhat.com> With my last fix, we're potentially scanning the roots twice: once for the initial-evacuation+update-refs, and if we run into OOM, another time to update remaining refs. This 2nd scan can cause problems in DerivedPointerTable: it asserts that every root is only visited once. This patch fixes it by enclosing each pass into DerivedPointerTable separately. http://cr.openjdk.java.net/~rkennke/fixdpt/webrev.00/ Ok? Roman From rkennke at redhat.com Tue Mar 7 11:11:08 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Mar 2017 12:11:08 +0100 Subject: RFR (XS): Relax assert to not fire at safepoint Message-ID: <4db2348e-6d2a-112b-0789-6fa9258d7b85@redhat.com> We're checking that a non-GC thread going into evacuate_object() does not hold the Threads_lock to prevent deadlock later. However, it can happen that the VMThread gets there via biased-locking-revokation, and this guy does hold the Threads_lock when it does. It seems ok to me to get there in this case. It will end up waiting for evacuation to stop, which should also be ok, since we *don't* stop GC threads on non-GC pauses, and those will eventually turn off evacuation. http://cr.openjdk.java.net/~rkennke/fixassert/webrev.01/ Ok? Roman From shade at redhat.com Tue Mar 7 11:30:23 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Mar 2017 12:30:23 +0100 Subject: RFR (XS): Fix DerivedPointerTable handling when scanning roots twice in init-evac phase In-Reply-To: <43ff2c18-6c34-eaa9-5fc0-b33c0b5c95ae@redhat.com> References: <43ff2c18-6c34-eaa9-5fc0-b33c0b5c95ae@redhat.com> Message-ID: <24a2b23c-3c5c-1f01-e34a-7a28a294fb91@redhat.com> On 03/07/2017 11:47 AM, Roman Kennke wrote: > With my last fix, we're potentially scanning the roots twice: once for > the initial-evacuation+update-refs, and if we run into OOM, another time > to update remaining refs. This 2nd scan can cause problems in > DerivedPointerTable: it asserts that every root is only visited once. > This patch fixes it by enclosing each pass into DerivedPointerTable > separately. > > http://cr.openjdk.java.net/~rkennke/fixdpt/webrev.00/ I don't get why do you need to duplicate update_pointers() call. Isn't it enough to clear the table when concgc was cancelled, and then let the rest run its course? if (cancelled_concgc()) { COMPILER2_PRESENT(DerivedPointerTable::clear()); ... } COMPILER2_PRESENT(DerivedPointerTable::update_pointers()); Thanks, -Aleksey From shade at redhat.com Tue Mar 7 11:34:47 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Mar 2017 12:34:47 +0100 Subject: RFR (XS): Relax assert to not fire at safepoint In-Reply-To: <4db2348e-6d2a-112b-0789-6fa9258d7b85@redhat.com> References: <4db2348e-6d2a-112b-0789-6fa9258d7b85@redhat.com> Message-ID: <7b1bc91e-9856-8e44-21c3-88bfc90b035d@redhat.com> On 03/07/2017 12:11 PM, Roman Kennke wrote: > We're checking that a non-GC thread going into evacuate_object() does > not hold the Threads_lock to prevent deadlock later. > > However, it can happen that the VMThread gets there via > biased-locking-revokation, and this guy does hold the Threads_lock when > it does. It seems ok to me to get there in this case. It will end up > waiting for evacuation to stop, which should also be ok, since we > *don't* stop GC threads on non-GC pauses, and those will eventually turn > off evacuation. > > http://cr.openjdk.java.net/~rkennke/fixassert/webrev.01/ Sounds fine. -Aleksey From rkennke at redhat.com Tue Mar 7 14:59:15 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Mar 2017 15:59:15 +0100 Subject: RFR (XS): Fix DerivedPointerTable handling when scanning roots twice in init-evac phase In-Reply-To: <24a2b23c-3c5c-1f01-e34a-7a28a294fb91@redhat.com> References: <43ff2c18-6c34-eaa9-5fc0-b33c0b5c95ae@redhat.com> <24a2b23c-3c5c-1f01-e34a-7a28a294fb91@redhat.com> Message-ID: Am 07.03.2017 um 12:30 schrieb Aleksey Shipilev: > On 03/07/2017 11:47 AM, Roman Kennke wrote: >> With my last fix, we're potentially scanning the roots twice: once for >> the initial-evacuation+update-refs, and if we run into OOM, another time >> to update remaining refs. This 2nd scan can cause problems in >> DerivedPointerTable: it asserts that every root is only visited once. >> This patch fixes it by enclosing each pass into DerivedPointerTable >> separately. >> >> http://cr.openjdk.java.net/~rkennke/fixdpt/webrev.00/ > I don't get why do you need to duplicate update_pointers() call. Isn't it enough > to clear the table when concgc was cancelled, and then let the rest run its course? > > if (cancelled_concgc()) { > COMPILER2_PRESENT(DerivedPointerTable::clear()); > ... > } > > COMPILER2_PRESENT(DerivedPointerTable::update_pointers()); clear() checks that the DPT is not active. If we call clear() without having called update_pointers() before, we get this assert: # Internal Error (/home/rkennke/src/openjdk/jdk9-shenandoah/hotspot/src/share/vm/compiler/oopMap.cpp:760), pid=1401, tid=1417 # assert(!_active) failed: should not be active (If I were to redesign DPT, I would make clear() and update_pointers() a scoped object...) Roman From shade at redhat.com Tue Mar 7 15:01:18 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Mar 2017 16:01:18 +0100 Subject: RFR (XS): Fix DerivedPointerTable handling when scanning roots twice in init-evac phase In-Reply-To: References: <43ff2c18-6c34-eaa9-5fc0-b33c0b5c95ae@redhat.com> <24a2b23c-3c5c-1f01-e34a-7a28a294fb91@redhat.com> Message-ID: <417b3614-0a37-1475-645f-45ca6baa5652@redhat.com> On 03/07/2017 03:59 PM, Roman Kennke wrote: > Am 07.03.2017 um 12:30 schrieb Aleksey Shipilev: >> On 03/07/2017 11:47 AM, Roman Kennke wrote: >>> With my last fix, we're potentially scanning the roots twice: once for >>> the initial-evacuation+update-refs, and if we run into OOM, another time >>> to update remaining refs. This 2nd scan can cause problems in >>> DerivedPointerTable: it asserts that every root is only visited once. >>> This patch fixes it by enclosing each pass into DerivedPointerTable >>> separately. >>> >>> http://cr.openjdk.java.net/~rkennke/fixdpt/webrev.00/ >> I don't get why do you need to duplicate update_pointers() call. Isn't it enough >> to clear the table when concgc was cancelled, and then let the rest run its course? >> >> if (cancelled_concgc()) { >> COMPILER2_PRESENT(DerivedPointerTable::clear()); >> ... >> } >> >> COMPILER2_PRESENT(DerivedPointerTable::update_pointers()); > > clear() checks that the DPT is not active. If we call clear() without > having called update_pointers() before, we get this assert: > > # Internal Error > (/home/rkennke/src/openjdk/jdk9-shenandoah/hotspot/src/share/vm/compiler/oopMap.cpp:760), > pid=1401, tid=1417 > # assert(!_active) failed: should not be active > > (If I were to redesign DPT, I would make clear() and update_pointers() a > scoped object...) D'oh, okay then. Put some comment about clear() should be preceded by update_pointers(). -Aleksey From roman at kennke.org Tue Mar 7 15:26:23 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 07 Mar 2017 15:26:23 +0000 Subject: hg: shenandoah/jdk9/hotspot: 2 new changesets Message-ID: <201703071526.v27FQNSP026694@aojmv0008.oracle.com> Changeset: fcb2d668c278 Author: rkennke Date: 2017-03-07 11:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/fcb2d668c278 Fix DerivedPointerTable handling when scanning roots twice in init-evac phase. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp Changeset: 253c4298bd49 Author: rkennke Date: 2017-03-07 16:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/253c4298bd49 Relax assert to not fire at safepoint. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp From rkennke at redhat.com Tue Mar 7 15:39:44 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Mar 2017 16:39:44 +0100 Subject: RFR: Implement barriers to maintain connection matrix In-Reply-To: <79e2c4a1-5e82-687f-b97c-e68dc3cc2e00@redhat.com> References: <79e2c4a1-5e82-687f-b97c-e68dc3cc2e00@redhat.com> Message-ID: <9a8231e8-a0a6-fa8f-1b79-d9092cfa2b92@redhat.com> Am 02.03.2017 um 11:13 schrieb Aleksey Shipilev: > On 03/01/2017 08:37 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/thematrix/webrev.00/ > *) c1_LIRGenerator.cpp: > > T_LONG does not sound right here. C1 should have something to deal with native > pointer width? > > 1683 LIR_Opr tmp4 = new_register(T_LONG); > 1684 __ move(LIR_OprFact::intptrConst((intptr_t) matrix->matrix_addr()), tmp4); Ok, right. new_pointer_register() does the right thing there. > *) referenceProcessor.cpp: > > That trailing boolean arg is obscure: > > 901 oop retest; > 902 if (UseShenandoahGC && UseShenandoahMatrix) { > 903 retest = oopDesc::atomic_compare_exchange_oop(next_discovered, > discovered_addr, > 904 NULL, true); > 905 } else { > 906 retest = oopDesc::atomic_compare_exchange_oop(next_discovered, > discovered_addr, > 907 NULL); > 908 } > > Is this just: > > oop retest = oopDesc::atomic_compare_exchange_oop(next_discovered, > discovered_addr, (UseShenandoahGC && UseShenandoahMatrix)); Yes, changed. > *) shenandoahConcurrentMark.cpp, ShenandoahRefProcTaskProxy.work: > > Am I blind, or the newly added branch under UseShenandoahMatrix is the same as > the branch on "else" path? Uhhh, forgot to finish that part :-) Fixed too. > *) shenandoahHeap.cpp, ShenandoahHeap::prepare_for_concurrent_evacuation() > > Bad indent. Fixed. > *) shenandoahOopClosures.hpp > > Confused why ShenandoahMarkRefsMatrixClosure uses CONCURRENT while > ShenandoahMarkRefsMetadataMatrixClosure uses NONE. These two should use the > same, no? Right. Fixed. > *) macro.cpp > > Put assert(UseShenandoahGC) here: > > 314 } else { > 315 C->shenandoah_eliminate_matrix_update(p2x, &_igvn); Fixed too. > Otherwise looks good. http://cr.openjdk.java.net/~rkennke/thematrix/webrev.01/ Ok now? Roman From shade at redhat.com Tue Mar 7 16:12:52 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Mar 2017 17:12:52 +0100 Subject: RFR: Implement barriers to maintain connection matrix In-Reply-To: <9a8231e8-a0a6-fa8f-1b79-d9092cfa2b92@redhat.com> References: <79e2c4a1-5e82-687f-b97c-e68dc3cc2e00@redhat.com> <9a8231e8-a0a6-fa8f-1b79-d9092cfa2b92@redhat.com> Message-ID: On 03/07/2017 04:39 PM, Roman Kennke wrote: >> Otherwise looks good. > http://cr.openjdk.java.net/~rkennke/thematrix/webrev.01/ > > Ok now? All right, good. Purge this before pushing: 5384 //movb(Address(rscratch1, tmp, Address::times_1), 3 /*true*/); Thanks, -Aleksey From roman at kennke.org Tue Mar 7 16:20:04 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 07 Mar 2017 16:20:04 +0000 Subject: hg: shenandoah/jdk9/hotspot: Implement barriers for maintaining connection matrix. Message-ID: <201703071620.v27GK5Sm012803@aojmv0008.oracle.com> Changeset: c1af6cf935a9 Author: rkennke Date: 2017-03-07 17:19 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/c1af6cf935a9 Implement barriers for maintaining connection matrix. ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LIR_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.inline.hpp + src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp + src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc/shenandoah/shenandoah_specialized_oop_closures.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp From shade at redhat.com Tue Mar 7 16:41:29 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Mar 2017 17:41:29 +0100 Subject: RFR (S): +UseCountedLoopSafepoints sets LoopStripMiningIters=1 Message-ID: Hi Found the bug when analyzing overnight runs: enabling -XX:+UseCLS sets LSM=1, not to LSM=1000, as our default. Which disables loop mining, argh. This is because +UseCLS fails FLAG_IS_DEFAULT test. Fixed, plus added tests: http://cr.openjdk.java.net/~shade/shenandoah/counted-loops-args/webrev.01/ Testing: hotspot_fast_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Tue Mar 7 17:13:30 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Mar 2017 18:13:30 +0100 Subject: RFR (S): +UseCountedLoopSafepoints sets LoopStripMiningIters=1 In-Reply-To: References: Message-ID: <3b40fbf1-c12b-7922-19e0-b88459fd3296@redhat.com> Am 07.03.2017 um 17:41 schrieb Aleksey Shipilev: > Hi > > Found the bug when analyzing overnight runs: enabling -XX:+UseCLS sets LSM=1, > not to LSM=1000, as our default. Which disables loop mining, argh. This is > because +UseCLS fails FLAG_IS_DEFAULT test. > > Fixed, plus added tests: > http://cr.openjdk.java.net/~shade/shenandoah/counted-loops-args/webrev.01/ > > Testing: hotspot_fast_gc_shenandoah Ok Roman From ashipile at redhat.com Tue Mar 7 17:14:54 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 07 Mar 2017 17:14:54 +0000 Subject: hg: shenandoah/jdk9/hotspot: +UseCountedLoopSafepoints sets LoopStripMiningIters=1. Message-ID: <201703071714.v27HEs2n027548@aojmv0008.oracle.com> Changeset: 05862926e822 Author: shade Date: 2017-03-07 18:14 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/05862926e822 +UseCountedLoopSafepoints sets LoopStripMiningIters=1. ! src/share/vm/runtime/arguments.cpp ! test/TEST.groups + test/gc/shenandoah/TestLoopMiningArguments.java From shade at redhat.com Tue Mar 7 17:16:27 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Mar 2017 18:16:27 +0100 Subject: RFR (XS): Matrix is always enabled with C2 Message-ID: <52b73bf0-d916-a0ad-1b31-b47af6b4e32c@redhat.com> Hi there, Turns out, C2 has matrix enabled unconditionally! Visible in generated code. Fix: http://cr.openjdk.java.net/~shade/shenandoah/matrix-c2-disable/webrev.01/ Thanks, -Aleksey From rkennke at redhat.com Tue Mar 7 17:19:18 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Mar 2017 18:19:18 +0100 Subject: RFR (XS): Matrix is always enabled with C2 In-Reply-To: <52b73bf0-d916-a0ad-1b31-b47af6b4e32c@redhat.com> References: <52b73bf0-d916-a0ad-1b31-b47af6b4e32c@redhat.com> Message-ID: <353ed691-8ad2-7b57-cf16-c0f096d6f57d@redhat.com> Am 07.03.2017 um 18:16 schrieb Aleksey Shipilev: > Hi there, > > Turns out, C2 has matrix enabled unconditionally! Visible in generated code. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-c2-disable/webrev.01/ > > Thanks, > -Aleksey Duh. Sure, go ahead! Thanks! Roman From ashipile at redhat.com Tue Mar 7 17:20:59 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 07 Mar 2017 17:20:59 +0000 Subject: hg: shenandoah/jdk9/hotspot: Matrix is always enabled with C2. Message-ID: <201703071720.v27HKx8S000110@aojmv0008.oracle.com> Changeset: d1f169eaeec9 Author: shade Date: 2017-03-07 18:20 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d1f169eaeec9 Matrix is always enabled with C2. ! src/share/vm/opto/graphKit.cpp From rkennke at redhat.com Wed Mar 8 12:03:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 8 Mar 2017 13:03:07 +0100 Subject: RFR (XS): Use unsigned comparison, fixes warnings in build Message-ID: <78832628-4f40-542f-9a1c-b9c4a3979b2f@redhat.com> As $SUBJECT says. Intent to push both jdk9+8u. http://cr.openjdk.java.net/~rkennke/fixwarning/webrev.00/ Roman From shade at redhat.com Wed Mar 8 12:05:40 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Mar 2017 13:05:40 +0100 Subject: RFR (XS): Use unsigned comparison, fixes warnings in build In-Reply-To: <78832628-4f40-542f-9a1c-b9c4a3979b2f@redhat.com> References: <78832628-4f40-542f-9a1c-b9c4a3979b2f@redhat.com> Message-ID: On 03/08/2017 01:03 PM, Roman Kennke wrote: > As $SUBJECT says. Intent to push both jdk9+8u. > > http://cr.openjdk.java.net/~rkennke/fixwarning/webrev.00/ Good. -Aleksey From rkennke at redhat.com Wed Mar 8 12:08:51 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 8 Mar 2017 13:08:51 +0100 Subject: RFR (XS) (JDK8u-only): Use 2-arg form of assert in non-LP64 branch Message-ID: This fixes build on i586 platform of jdk8u. http://cr.openjdk.java.net/~rkennke/fixassert-i587/webrev.00/ Roman From roman at kennke.org Wed Mar 8 12:10:29 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 08 Mar 2017 12:10:29 +0000 Subject: hg: shenandoah/jdk9/hotspot: Use unsigned comparison, fixes warnings in build. Message-ID: <201703081210.v28CATxG012846@aojmv0008.oracle.com> Changeset: 8966b5fe53ce Author: rkennke Date: 2017-03-08 12:50 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/8966b5fe53ce Use unsigned comparison, fixes warnings in build. ! src/share/vm/opto/shenandoahSupport.cpp From shade at redhat.com Wed Mar 8 12:10:24 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Mar 2017 13:10:24 +0100 Subject: RFR (XS) (JDK8u-only): Use 2-arg form of assert in non-LP64 branch In-Reply-To: References: Message-ID: <9242604a-b15e-fb14-e2f3-a2a09822911f@redhat.com> On 03/08/2017 01:08 PM, Roman Kennke wrote: > This fixes build on i586 platform of jdk8u. > > http://cr.openjdk.java.net/~rkennke/fixassert-i587/webrev.00/ Good, thank you. -Aleksey From roman at kennke.org Wed Mar 8 12:30:10 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 08 Mar 2017 12:30:10 +0000 Subject: hg: shenandoah/jdk8u/hotspot: 2 new changesets Message-ID: <201703081230.v28CUBW0017959@aojmv0008.oracle.com> Changeset: 626e8061a03e Author: rkennke Date: 2017-03-08 12:50 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/626e8061a03e Use unsigned comparison, fixes warnings in build. ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 9467884f3272 Author: rkennke Date: 2017-03-08 13:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/9467884f3272 Use 2-arg form of assert in non-LP64 branch. ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp From mvala at redhat.com Wed Mar 8 14:18:50 2017 From: mvala at redhat.com (Michal Vala) Date: Wed, 8 Mar 2017 15:18:50 +0100 Subject: RFR: GensrcMisc.gmk linker issue on windows Message-ID: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> Hi, we're unable to build on windows due to link issue /out:genSocketOptionRegistry.exe /out:ut:r:/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.exe r:/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.obj LINK : fatal error LNK1104: cannot open file 'ut:r:/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.exe' make[2]: *** [gensrc/GensrcMisc.gmk:75: /cygdrive/r/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.exe] Error 2 This fix the issue: aarch64-port/jdk8u - https://michalvala.fedorapeople.org/webrevs/gensrcmisclinker-aarch64/webrev.00/ aarch64-port/jdk8u-shenandoah - https://michalvala.fedorapeople.org/webrevs/gensrcmisclinker-aarch64-shenandoah/webrev.00/ -- -Michal From mvala at redhat.com Thu Mar 9 07:24:04 2017 From: mvala at redhat.com (Michal Vala) Date: Thu, 9 Mar 2017 08:24:04 +0100 Subject: [aarch64-port-dev ] RFR: GensrcMisc.gmk linker issue on windows In-Reply-To: <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> References: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> Message-ID: <664efa9a-1b45-0303-d6f2-10e393e74d7c@redhat.com> > Have you tested that reverting this to the upstream jdk8u version doesn't break aarch64? > > I did a comparison of upstream jdk8u121-b14 with the current state of aarch64/jdk8u (attached) > and all other changes do seem to be necessary for aarch64 (the test issue is a merge issue > already resolved in the main jdk8u tree, but not jdk8u121-b14). > Haven't tried on aarch64, but I'll do. -- -Michal From mvala at redhat.com Thu Mar 9 13:04:32 2017 From: mvala at redhat.com (Michal Vala) Date: Thu, 9 Mar 2017 14:04:32 +0100 Subject: [aarch64-port-dev ] RFR: GensrcMisc.gmk linker issue on windows In-Reply-To: <664efa9a-1b45-0303-d6f2-10e393e74d7c@redhat.com> References: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> <664efa9a-1b45-0303-d6f2-10e393e74d7c@redhat.com> Message-ID: <84083dd8-5207-7a49-d49b-304802bc70e3@redhat.com> On 03/09/2017 08:24 AM, Michal Vala wrote: > >> Have you tested that reverting this to the upstream jdk8u version >> doesn't break aarch64? >> >> I did a comparison of upstream jdk8u121-b14 with the current state of >> aarch64/jdk8u (attached) >> and all other changes do seem to be necessary for aarch64 (the test >> issue is a merge issue >> already resolved in the main jdk8u tree, but not jdk8u121-b14). >> > > Haven't tried on aarch64, but I'll do. > How you please got the patch? I just could find this huge merge changeset under the hash [1]. If I tried to revert patch you sent "patch -R -p1 < ~/tmp/aarch64.jdk.patch" I got following error on aarch64: gmake[2]: *** No rule to make target `/mnt/ramdisk/tmp/aarch64-port-jdk8u/jdk/src/solaris/bin/aarch64/jvm.cfg', needed by `/mnt/ramdisk/tmp/aarch64-port-jdk8u/build/linux-aarch64-normal-server-release/jdk/lib/aarch64/jvm.cfg'. Stop. With just LDEXE fix I sent, aarch64 build is ok. -- -Michal [1] - http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/391be061dfc7 From akashche at redhat.com Thu Mar 9 13:46:31 2017 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 9 Mar 2017 13:46:31 +0000 Subject: [aarch64-port-dev ] RFR: GensrcMisc.gmk linker issue on windows In-Reply-To: <84083dd8-5207-7a49-d49b-304802bc70e3@redhat.com> References: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> <664efa9a-1b45-0303-d6f2-10e393e74d7c@redhat.com> <84083dd8-5207-7a49-d49b-304802bc70e3@redhat.com> Message-ID: <1ac4e237-6e57-5b63-7b64-7eccadb70f2c@redhat.com> Hi, On 03/09/2017 01:04 PM, Michal Vala wrote: > > > On 03/09/2017 08:24 AM, Michal Vala wrote: >> >>> Have you tested that reverting this to the upstream jdk8u version >>> doesn't break aarch64? >>> >>> I did a comparison of upstream jdk8u121-b14 with the current state of >>> aarch64/jdk8u (attached) >>> and all other changes do seem to be necessary for aarch64 (the test >>> issue is a merge issue >>> already resolved in the main jdk8u tree, but not jdk8u121-b14). >>> >> >> Haven't tried on aarch64, but I'll do. >> > > How you please got the patch? I just could find this huge merge > changeset under the hash [1]. > > If I tried to revert patch you sent "patch -R -p1 < > ~/tmp/aarch64.jdk.patch" I got following error on aarch64: > > gmake[2]: *** No rule to make target > `/mnt/ramdisk/tmp/aarch64-port-jdk8u/jdk/src/solaris/bin/aarch64/jvm.cfg', > needed by > `/mnt/ramdisk/tmp/aarch64-port-jdk8u/build/linux-aarch64-normal-server-release/jdk/lib/aarch64/jvm.cfg'. > Stop. > > > With just LDEXE fix I sent, aarch64 build is ok. I contributed the opposite change once for aarch32 [1]. Just checked with aarch64-jdk8u - proposed change breaks aarch64 cross-compilation (on ubuntu 16.04 x86_64 with --openjdk-target=aarch64-linux-gnu ) causing the following error: /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0 /home/aarch64/jdk8u-aarch64/build/linux-aarch64-normal-server-release/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.o: In function `out': genSocketOptionRegistry.c:(.text+0x10): undefined reference to `puts' /home/aarch64/jdk8u-aarch64/build/linux-aarch64-normal-server-release/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.o: In function `emit': genSocketOptionRegistry.c:(.text+0x48): undefined reference to `printf' genSocketOptionRegistry.c:(.text+0x5c): undefined reference to `printf' gensrc/GensrcMisc.gmk:74: recipe for target '/home/aarch64/jdk8u-aarch64/build/linux-aarch64-normal-server-release/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry' failed make[2]: *** [/home/aarch64/jdk8u-aarch64/build/linux-aarch64-normal-server-release/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry] Error 1 Though this change is indeed required for windows builds, ojdkbuild brings a local patch for it [2]. [1] http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-February/000111.html [2] https://github.com/ojdkbuild/lookaside_java-1.8.0-openjdk/commit/e71366e75cabf16c0c7bd7789ec37b4f2925f93f -- -Alex From rkennke at redhat.com Thu Mar 9 14:49:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 9 Mar 2017 15:49:21 +0100 Subject: RFR (XS): Fix Shenandoah argument checking on 32bit builds Message-ID: <6c7cca0d-13cb-c1e4-6551-04ecde245e85@redhat.com> This #ifdef _LP64 the part where we check for address space overflow when using the optimized ObjArrayChunkedTask. On JDK8u, this also replaces the use of the (2-arg) UNSUPPORTED_OPTION with the 1-arg UNSUPPORTED_GC_OPTION (which was replaces with a 1-arg UNSUPPORTED_OPTION in JDK9). http://cr.openjdk.java.net/~rkennke/fixargchecks32/webrev.00/ Roman From shade at redhat.com Thu Mar 9 14:51:38 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 Mar 2017 15:51:38 +0100 Subject: RFR (XS): Fix Shenandoah argument checking on 32bit builds In-Reply-To: <6c7cca0d-13cb-c1e4-6551-04ecde245e85@redhat.com> References: <6c7cca0d-13cb-c1e4-6551-04ecde245e85@redhat.com> Message-ID: <3f71cd33-d39d-995d-7dfd-370685e3c3e6@redhat.com> On 03/09/2017 03:49 PM, Roman Kennke wrote: > This #ifdef _LP64 the part where we check for address space overflow > when using the optimized ObjArrayChunkedTask. > > On JDK8u, this also replaces the use of the (2-arg) UNSUPPORTED_OPTION > with the 1-arg UNSUPPORTED_GC_OPTION (which was replaces with a 1-arg > UNSUPPORTED_OPTION in JDK9). > > http://cr.openjdk.java.net/~rkennke/fixargchecks32/webrev.00/ OK. -Aleksey From roman at kennke.org Thu Mar 9 14:52:52 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 09 Mar 2017 14:52:52 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix Shenandoah argument checking on 32bit builds. Message-ID: <201703091452.v29Eqqrr028091@aojmv0008.oracle.com> Changeset: e4a4414151f0 Author: rkennke Date: 2017-03-09 15:50 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e4a4414151f0 Fix Shenandoah argument checking on 32bit builds. ! src/share/vm/runtime/arguments.cpp From roman at kennke.org Thu Mar 9 14:53:07 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 09 Mar 2017 14:53:07 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix Shenandoah argument checking on 32bit builds. Message-ID: <201703091453.v29Er7Ot028222@aojmv0008.oracle.com> Changeset: 49cc7fecb14d Author: rkennke Date: 2017-03-09 15:51 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/49cc7fecb14d Fix Shenandoah argument checking on 32bit builds. ! src/share/vm/runtime/arguments.cpp From shade at redhat.com Thu Mar 9 16:30:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 Mar 2017 17:30:06 +0100 Subject: RFR (S): Shenandoah matrix update barriers should be conditional Message-ID: <51da1e01-17e8-1586-cde3-46abe54b1233@redhat.com> ...otherwise we are contending on matrix updates a lot. Case in point. Storing the object in different threads to different fields: Benchmark Mode Cnt Score Error Units # -Xint Plain.test_Object avgt 5 152.070 ? 0.378 ns/op # baseline Plain.test_Object avgt 5 129.156 ? 6.325 ns/op # patched # C1 Plain.test_Object avgt 5 42.110 ? 1.008 ns/op # baseline Plain.test_Object avgt 5 7.693 ? 0.031 ns/op # patched # C2 Plain.test_Object avgt 5 41.746 ? 0.120 ns/op # baseline Plain.test_Object avgt 5 6.792 ? 0.109 ns/op # patched Patch: http://cr.openjdk.java.net/~shade/shenandoah/matrix-update-cond/webrev.01/ Testing: hotspot_gc_shenandoah, jcstress -m quick with matrix enabled, eyeballing assembly Thanks, -Aleksey P.S. I am seriously considering to change bool* to char*, to avoid this C++ bool mess. From rkennke at redhat.com Thu Mar 9 17:33:44 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 9 Mar 2017 18:33:44 +0100 Subject: RFR (S): Shenandoah matrix update barriers should be conditional In-Reply-To: <51da1e01-17e8-1586-cde3-46abe54b1233@redhat.com> References: <51da1e01-17e8-1586-cde3-46abe54b1233@redhat.com> Message-ID: <6b911111-0d8d-b441-507c-1b1f788310cc@redhat.com> Am 09.03.2017 um 17:30 schrieb Aleksey Shipilev: > ...otherwise we are contending on matrix updates a lot. > > Case in point. Storing the object in different threads to different fields: > > Benchmark Mode Cnt Score Error Units > > # -Xint > Plain.test_Object avgt 5 152.070 ? 0.378 ns/op # baseline > Plain.test_Object avgt 5 129.156 ? 6.325 ns/op # patched > > # C1 > Plain.test_Object avgt 5 42.110 ? 1.008 ns/op # baseline > Plain.test_Object avgt 5 7.693 ? 0.031 ns/op # patched > > # C2 > Plain.test_Object avgt 5 41.746 ? 0.120 ns/op # baseline > Plain.test_Object avgt 5 6.792 ? 0.109 ns/op # patched > > Patch: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-update-cond/webrev.01/ Wow. Yes, of course! Out of curiousity, how do the numbers look without matrix? > P.S. I am seriously considering to change bool* to char*, to avoid this C++ bool > mess. Please go ahead. If we ever encounter a platform that compiles bool to more than one byte, our matrix goes through the roof ;-) Roman From ashipile at redhat.com Thu Mar 9 17:51:25 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 09 Mar 2017 17:51:25 +0000 Subject: hg: shenandoah/jdk9/hotspot: Shenandoah matrix update barriers should be conditional. Message-ID: <201703091751.v29HpPjO025574@aojmv0008.oracle.com> Changeset: 927522e04185 Author: shade Date: 2017-03-09 18:50 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/927522e04185 Shenandoah matrix update barriers should be conditional. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp From shade at redhat.com Thu Mar 9 17:51:36 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 Mar 2017 18:51:36 +0100 Subject: RFR (S): Shenandoah matrix update barriers should be conditional In-Reply-To: <6b911111-0d8d-b441-507c-1b1f788310cc@redhat.com> References: <51da1e01-17e8-1586-cde3-46abe54b1233@redhat.com> <6b911111-0d8d-b441-507c-1b1f788310cc@redhat.com> Message-ID: On 03/09/2017 06:33 PM, Roman Kennke wrote: > Out of curiousity, how do the numbers look without matrix? I'll do that exercise when optimizing the single-threaded performance. >> P.S. I am seriously considering to change bool* to char*, to avoid this C++ bool >> mess. > Please go ahead. If we ever encounter a platform that compiles bool to > more than one byte, our matrix goes through the roof ;-) ...but this goes first! -Aleksey From shade at redhat.com Thu Mar 9 18:58:46 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 Mar 2017 19:58:46 +0100 Subject: RFR (S): Connection matrix should be char*, not bool* Message-ID: Hi, C++ Standard guarantees sizeof(char) = 1. It does not guarantee the same for sizeof(bool). Therefore, having char* matrix is safer. Here: http://cr.openjdk.java.net/~shade/shenandoah/matrix-byte/webrev.01/ Testing: hotspot_gc_shenandoah, jcstress -m quick with matrix verification Thanks, -Aleksey From rkennke at redhat.com Thu Mar 9 19:01:44 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 9 Mar 2017 20:01:44 +0100 Subject: RFR (S): Connection matrix should be char*, not bool* In-Reply-To: References: Message-ID: <63f244e4-2af4-2831-8692-4875b7695988@redhat.com> Am 09.03.2017 um 19:58 schrieb Aleksey Shipilev: > Hi, > > C++ Standard guarantees sizeof(char) = 1. It does not guarantee the same for > sizeof(bool). Therefore, having char* matrix is safer. Here: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-byte/webrev.01/ > > Testing: hotspot_gc_shenandoah, jcstress -m quick with matrix verification > > Thanks, > -Aleksey > Yup! From ashipile at redhat.com Thu Mar 9 19:05:26 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 09 Mar 2017 19:05:26 +0000 Subject: hg: shenandoah/jdk9/hotspot: Connection matrix should be char*, not bool*. Message-ID: <201703091905.v29J5Qc5016489@aojmv0008.oracle.com> Changeset: d068ee404af1 Author: shade Date: 2017-03-09 20:04 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d068ee404af1 Connection matrix should be char*, not bool*. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp ! src/share/vm/opto/graphKit.cpp From ashipile at redhat.com Thu Mar 9 19:45:02 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 09 Mar 2017 19:45:02 +0000 Subject: hg: shenandoah/jdk9/hotspot: ShenandoahConnectionMatrix destructor should use char, not bool. Message-ID: <201703091945.v29Jj2bK027255@aojmv0008.oracle.com> Changeset: 7172b25dd700 Author: shade Date: 2017-03-09 20:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/7172b25dd700 ShenandoahConnectionMatrix destructor should use char, not bool. ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp From shade at redhat.com Fri Mar 10 11:36:24 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Mar 2017 12:36:24 +0100 Subject: RFR (S): C2: Matrix update barrier math improvements Message-ID: Hi, Turns out, we can do a few math transformations for computing matrix index, that benefits performance. See here: http://cr.openjdk.java.net/~shade/shenandoah/matrix-math/webrev.01/ I think it only deserves to be in C2. Fighting C1 codegen to arrive to the same code is a waste of time, IMO. It seems to cut the matrix barrier costs almost in half: Benchmark Mode Cnt Score Error Units # Baseline (no barriers) Plain.test_Object avgt 15 4.683 ? 0.031 ns/op Plain.test_Object:cycles avgt 3 18.627 ? 1.466 #/op Plain.test_Object:instructions avgt 3 29.023 ? 0.059 #/op # Baseline (-XX:+ShenandoahMatrix) Plain.test_Object avgt 15 6.629 ? 0.054 ns/op Plain.test_Object:cycles avgt 3 26.392 ? 2.251 #/op Plain.test_Object:instructions avgt 3 45.047 ? 0.769 #/op # Patched (-XX:+ShenandoahMatrix) Plain.test_Object avgt 15 5.873 ? 0.038 ns/op Plain.test_Object:cycles avgt 3 23.373 ? 0.339 #/op Plain.test_Object:instructions avgt 3 41.096 ? 0.333 #/op Generated code before/after: http://cr.openjdk.java.net/~shade/shenandoah/matrix-math/baseline.perfasm http://cr.openjdk.java.net/~shade/shenandoah/matrix-math/optimized.perfasm Testing: hotspot_gc_shenandoah, jcstress -m quick (matrix update) is running Thanks, -Aleksey From rkennke at redhat.com Fri Mar 10 13:10:33 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 10 Mar 2017 14:10:33 +0100 Subject: RFR (S): C2: Matrix update barrier math improvements In-Reply-To: References: Message-ID: <01fb8f8e-c15a-1291-0db6-bdb7e53df63d@redhat.com> Am 10.03.2017 um 12:36 schrieb Aleksey Shipilev: > Hi, > > Turns out, we can do a few math transformations for computing matrix index, that > benefits performance. See here: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-math/webrev.01/ > > I think it only deserves to be in C2. Fighting C1 codegen to arrive to the same > code is a waste of time, IMO. It seems to cut the matrix barrier costs almost in > half: > > Benchmark Mode Cnt Score Error Units > > # Baseline (no barriers) > Plain.test_Object avgt 15 4.683 ? 0.031 ns/op > Plain.test_Object:cycles avgt 3 18.627 ? 1.466 #/op > Plain.test_Object:instructions avgt 3 29.023 ? 0.059 #/op > > # Baseline (-XX:+ShenandoahMatrix) > Plain.test_Object avgt 15 6.629 ? 0.054 ns/op > Plain.test_Object:cycles avgt 3 26.392 ? 2.251 #/op > Plain.test_Object:instructions avgt 3 45.047 ? 0.769 #/op > > # Patched (-XX:+ShenandoahMatrix) > Plain.test_Object avgt 15 5.873 ? 0.038 ns/op > Plain.test_Object:cycles avgt 3 23.373 ? 0.339 #/op > Plain.test_Object:instructions avgt 3 41.096 ? 0.333 #/op > > Generated code before/after: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-math/baseline.perfasm > http://cr.openjdk.java.net/~shade/shenandoah/matrix-math/optimized.perfasm > > Testing: hotspot_gc_shenandoah, jcstress -m quick (matrix update) is running > > Thanks, > -Aleksey > Great stuff! Yes! Roman From ashipile at redhat.com Fri Mar 10 14:30:21 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 10 Mar 2017 14:30:21 +0000 Subject: hg: shenandoah/jdk9/hotspot: C2: Matrix update barrier math improvements. Message-ID: <201703101430.v2AEUMh9011319@aojmv0008.oracle.com> Changeset: a188e0e43a45 Author: shade Date: 2017-03-10 15:29 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a188e0e43a45 C2: Matrix update barrier math improvements. ! src/share/vm/opto/graphKit.cpp From shade at redhat.com Fri Mar 10 14:41:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Mar 2017 15:41:01 +0100 Subject: RFR (XS): Temporarily disable ArrayCopyLoadStoreMaxElem with UseShenandoahMatrix Message-ID: <9c5a53dc-4c40-cc55-8b34-fb3444de2231@redhat.com> This avoids compiler bug we know about, and let us do more extensive performance experiments meanwhile: diff -r a188e0e43a45 src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Fri Mar 10 15:29:45 2017 +0100 +++ b/src/share/vm/runtime/arguments.cpp Fri Mar 10 15:39:26 2017 +0100 @@ -2098,6 +2098,11 @@ FLAG_SET_DEFAULT(AlwaysPreTouch, false); FLAG_SET_DEFAULT(ShenandoahAlwaysPreTouch, true); } + + if (UseShenandoahMatrix && FLAG_IS_DEFAULT(ArrayCopyLoadStoreMaxElem)) { + warning("UseShenandoahMatrix is enabled, setting ArrayCopyLoadStoreMaxElem=0 to avoid compiler bug"); + FLAG_SET_DEFAULT(ArrayCopyLoadStoreMaxElem, 0); + } } void Arguments::set_gc_specific_flags() { Thanks, -Aleksey From rkennke at redhat.com Fri Mar 10 14:58:39 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 10 Mar 2017 15:58:39 +0100 Subject: RFR (XS): Temporarily disable ArrayCopyLoadStoreMaxElem with UseShenandoahMatrix In-Reply-To: <9c5a53dc-4c40-cc55-8b34-fb3444de2231@redhat.com> References: <9c5a53dc-4c40-cc55-8b34-fb3444de2231@redhat.com> Message-ID: <7999c372-7a9c-1ecc-c7ac-7f6c3d228d6f@redhat.com> Am 10.03.2017 um 15:41 schrieb Aleksey Shipilev: > This avoids compiler bug we know about, and let us do more extensive performance > experiments meanwhile: > > diff -r a188e0e43a45 src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp Fri Mar 10 15:29:45 2017 +0100 > +++ b/src/share/vm/runtime/arguments.cpp Fri Mar 10 15:39:26 2017 +0100 > @@ -2098,6 +2098,11 @@ > FLAG_SET_DEFAULT(AlwaysPreTouch, false); > FLAG_SET_DEFAULT(ShenandoahAlwaysPreTouch, true); > } > + > + if (UseShenandoahMatrix && FLAG_IS_DEFAULT(ArrayCopyLoadStoreMaxElem)) { > + warning("UseShenandoahMatrix is enabled, setting > ArrayCopyLoadStoreMaxElem=0 to avoid compiler bug"); > + FLAG_SET_DEFAULT(ArrayCopyLoadStoreMaxElem, 0); > + } > } > > void Arguments::set_gc_specific_flags() { > > Thanks, > -Aleksey > > Makes sense, yes. Please push! Roman From ashipile at redhat.com Fri Mar 10 14:59:55 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 10 Mar 2017 14:59:55 +0000 Subject: hg: shenandoah/jdk9/hotspot: Temporarily disable ArrayCopyLoadStoreMaxElem with UseShenandoahMatrix. Message-ID: <201703101459.v2AExtsj022241@aojmv0008.oracle.com> Changeset: aebc438718fd Author: shade Date: 2017-03-10 15:59 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/aebc438718fd Temporarily disable ArrayCopyLoadStoreMaxElem with UseShenandoahMatrix. ! src/share/vm/runtime/arguments.cpp From shade at redhat.com Fri Mar 10 15:19:37 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Mar 2017 16:19:37 +0100 Subject: Heads up: C2 SEGV with Compiler.sunflow with -XX:+UseShenandoahMatrix Message-ID: <9fe8a8ee-f465-c786-50f1-fd7613760b29@redhat.com> Comes from here: $ hg diff diff -r aebc438718fd src/share/vm/opto/macroArrayCopy.cpp --- a/src/share/vm/opto/macroArrayCopy.cpp Fri Mar 10 15:59:19 2017 +0100 +++ b/src/share/vm/opto/macroArrayCopy.cpp Fri Mar 10 16:15:58 2017 +0100 @@ -949,6 +949,7 @@ transform_later(call); extract_call_projections(call); + assert (_fallthroughcatchproj != NULL, "sanity"); *ctrl = _fallthroughcatchproj->clone(); transform_later(*ctrl); I wonder if this means our graph is garbled around array copies. Thanks, -Aleksey From shade at redhat.com Fri Mar 10 18:30:41 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Mar 2017 19:30:41 +0100 Subject: RFR (S): Connection matrix printout, enable in product, reformat Message-ID: <050fd93f-0ce6-89f6-9cf5-5909705eada1@redhat.com> Hi, Please see the changes in PrintShenandoahMatrix that enable it in product bits, and also formats nicely: http://cr.openjdk.java.net/~shade/shenandoah/matrix-print/webrev.01/ (Also note VerifyShenandoahMatrix was *not* enabled for product during concmark, only for mark-compact!) Testing: hotspot_gc_shenandoah Sample output: https://paste.fedoraproject.org/paste/JtwF3HM4UpPP1cKFgggGgl5M1UNdIGYhyRLivL9gydE= -Aleksey From rkennke at redhat.com Fri Mar 10 20:52:02 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 10 Mar 2017 15:52:02 -0500 (EST) Subject: RFR (S): Connection matrix printout, enable in product, reformat Message-ID: <1781724755.509513.1489179122398.JavaMail.zimbra@zmail25.collab.prod.int.phx2.redhat.com> Jawohl! ;-) Can't see the pastebin though.. RomanAm 10.03.2017 7:31 nachm. schrieb Aleksey Shipilev : > > Hi, > > Please see the changes in PrintShenandoahMatrix that enable it in product bits, > and also formats nicely: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-print/webrev.01/ > > (Also note VerifyShenandoahMatrix was *not* enabled for product during concmark, > only for mark-compact!) > > Testing: hotspot_gc_shenandoah > > Sample output: > https://paste.fedoraproject.org/paste/JtwF3HM4UpPP1cKFgggGgl5M1UNdIGYhyRLivL9gydE= > > -Aleksey > From ashipile at redhat.com Fri Mar 10 20:53:36 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 10 Mar 2017 20:53:36 +0000 Subject: hg: shenandoah/jdk9/hotspot: Connection matrix printout, enable in product, reformat. Message-ID: <201703102053.v2AKra4i002489@aojmv0008.oracle.com> Changeset: a75a96eaf160 Author: shade Date: 2017-03-10 21:53 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a75a96eaf160 Connection matrix printout, enable in product, reformat. ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp From rwestrel at redhat.com Mon Mar 13 08:54:56 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Mon, 13 Mar 2017 08:54:56 +0000 Subject: hg: shenandoah/jdk9/hotspot: fix matrix update elimination Message-ID: <201703130854.v2D8suXE016043@aojmv0008.oracle.com> Changeset: cbed110535d4 Author: roland Date: 2017-03-13 09:52 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/cbed110535d4 fix matrix update elimination ! src/share/vm/opto/compile.cpp From rwestrel at redhat.com Mon Mar 13 08:55:09 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 13 Mar 2017 09:55:09 +0100 Subject: Heads up: C2 SEGV with Compiler.sunflow with -XX:+UseShenandoahMatrix In-Reply-To: <9fe8a8ee-f465-c786-50f1-fd7613760b29@redhat.com> References: <9fe8a8ee-f465-c786-50f1-fd7613760b29@redhat.com> Message-ID: That one should be fixed now. Roland. From mvala at redhat.com Mon Mar 13 09:20:59 2017 From: mvala at redhat.com (Michal Vala) Date: Mon, 13 Mar 2017 10:20:59 +0100 Subject: [aarch64-port-dev ] RFR: GensrcMisc.gmk linker issue on windows In-Reply-To: <1ac4e237-6e57-5b63-7b64-7eccadb70f2c@redhat.com> References: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> <664efa9a-1b45-0303-d6f2-10e393e74d7c@redhat.com> <84083dd8-5207-7a49-d49b-304802bc70e3@redhat.com> <1ac4e237-6e57-5b63-7b64-7eccadb70f2c@redhat.com> Message-ID: <23e52ba5-859f-8e72-32c4-a9c206ce13d2@redhat.com> On 03/09/2017 02:46 PM, Alex Kashchenko wrote: > > I contributed the opposite change once for aarch32 [1]. Just checked > with aarch64-jdk8u - proposed change breaks aarch64 cross-compilation > (on ubuntu 16.04 x86_64 with --openjdk-target=aarch64-linux-gnu ) > > Though this change is indeed required for windows builds, ojdkbuild > brings a local patch for it [2]. > ok, so what's the result of this for aarch64-port/jdk8u and aarch64-port/jdk8u-shenandoah ? It breaks cross-compile but fix windows build. Upstream jdk8u has fixed version[3] > > [1] > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-February/000111.html > > [2] > https://github.com/ojdkbuild/lookaside_java-1.8.0-openjdk/commit/e71366e75cabf16c0c7bd7789ec37b4f2925f93f > > -- -Michal [3] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/8c93eb3fa1c0/make/gensrc/GensrcMisc.gmk#l79 From aph at redhat.com Mon Mar 13 09:33:41 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Mar 2017 09:33:41 +0000 Subject: [aarch64-port-dev ] RFR: GensrcMisc.gmk linker issue on windows In-Reply-To: <23e52ba5-859f-8e72-32c4-a9c206ce13d2@redhat.com> References: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> <664efa9a-1b45-0303-d6f2-10e393e74d7c@redhat.com> <84083dd8-5207-7a49-d49b-304802bc70e3@redhat.com> <1ac4e237-6e57-5b63-7b64-7eccadb70f2c@redhat.com> <23e52ba5-859f-8e72-32c4-a9c206ce13d2@redhat.com> Message-ID: On 13/03/17 09:20, Michal Vala wrote: > ok, so what's the result of this for aarch64-port/jdk8u and > aarch64-port/jdk8u-shenandoah ? > > It breaks cross-compile but fix windows build. Upstream jdk8u has fixed > version[3] This discussion has gone on for a very long time. I can't see any analysis of the problem which indicates what the actual problem is, and why the needs differ. Andrew. From shade at redhat.com Mon Mar 13 10:37:04 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 11:37:04 +0100 Subject: Heads up: C2 SEGV with Compiler.sunflow with -XX:+UseShenandoahMatrix In-Reply-To: References: <9fe8a8ee-f465-c786-50f1-fd7613760b29@redhat.com> Message-ID: <7b3ebdcd-dcbe-888a-f741-9e6ee5ca3861@redhat.com> On 03/13/2017 09:55 AM, Roland Westrelin wrote: > That one should be fixed now. Confirmed. Thank you! -Aleksey From shade at redhat.com Mon Mar 13 12:06:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 13:06:42 +0100 Subject: RFR (S): Cherry pick fix for "8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect" Message-ID: Hi, I want to cherry-pick this change to let updated jcstress pass the tests: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2ff05d967fb2 Thanks, -Aleksey From rkennke at redhat.com Mon Mar 13 12:45:58 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 13 Mar 2017 13:45:58 +0100 Subject: RFR (S): Cherry pick fix for "8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect" In-Reply-To: References: Message-ID: <5A253A89-83DB-405F-B58F-FEBB2A84A3F9@redhat.com> Ok Am 13. M?rz 2017 13:06:42 MEZ schrieb Aleksey Shipilev : >Hi, > >I want to cherry-pick this change to let updated jcstress pass the >tests: > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2ff05d967fb2 > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From ashipile at redhat.com Mon Mar 13 12:48:18 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 13 Mar 2017 12:48:18 +0000 Subject: hg: shenandoah/jdk9/hotspot: Cherry pick fix for "8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect". Message-ID: <201703131248.v2DCmIiu023139@aojmv0008.oracle.com> Changeset: cba65b85b10c Author: shade Date: 2017-03-13 13:14 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/cba65b85b10c Cherry pick fix for "8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect". ! src/share/vm/c1/c1_ValueMap.hpp + test/compiler/c1/UnsafeVolatileGuardTest.java + test/compiler/c1/VolatileGuardTest.java From zgu at redhat.com Mon Mar 13 14:44:45 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 13 Mar 2017 10:44:45 -0400 Subject: RFR(M): Extend work gang dispatcher for low latency task handoff Message-ID: Hi, This patch provides the capability to group work gang tasks into sessions, which allows low-latency task handoff by keeping workers hot. As expected, it only benefits parallel phases, but hurts concurrent phases. I think that the approach does not reach its max benefit due to not be able to schedule or queue tasks in advance. The statistics shows that 80% of workers rendezvous during spinning phases, but 20% during yield phases, which might delay the handoff. Also the task submission thread, any spins or yields seem only hurts performance, so have to fallback to semaphore, maybe introduce another latency. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/webrev.00/ I would appreciate any suggestions! Performance: SPECjbb2015: It shows improvement when it is enabled for parallel phases. Current head: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/baseline_without_patch.txt With patch, but disabled: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/baseline_with_patch.txt Enable for parallel phases only: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/par_session.txt Compile.sunflow on local machine: It shows slight drop. Current head: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/sunflow_without_patch.txt With patch, but disabled: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/sunflow_no_session.txt Enabled for parallel phases only: http://cr.openjdk.java.net/~zgu/shenandoah/work_session/sunflow_par_session.txt Thanks, -Zhengyu From aph at redhat.com Mon Mar 13 15:59:13 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Mar 2017 15:59:13 +0000 Subject: RFR (S): Cherry pick fix for "8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect" In-Reply-To: References: Message-ID: <5d4cd2a5-ec85-7052-3c84-cc35fcce3593@redhat.com> On 13/03/17 12:06, Aleksey Shipilev wrote: > I want to cherry-pick this change to let updated jcstress pass the tests: > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2ff05d967fb2 Is this also a bug in earlier releases of OpenJDK? Andrew. From shade at redhat.com Mon Mar 13 16:52:21 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 17:52:21 +0100 Subject: RFR (S): Cherry pick fix for "8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect" In-Reply-To: <5d4cd2a5-ec85-7052-3c84-cc35fcce3593@redhat.com> References: <5d4cd2a5-ec85-7052-3c84-cc35fcce3593@redhat.com> Message-ID: <542c9977-04f0-b451-0bc8-a204af9b854b@redhat.com> On 03/13/2017 04:59 PM, Andrew Haley wrote: > On 13/03/17 12:06, Aleksey Shipilev wrote: >> I want to cherry-pick this change to let updated jcstress pass the tests: >> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2ff05d967fb2 > > Is this also a bug in earlier releases of OpenJDK? Yes, there is a backport for 8u: https://bugs.openjdk.java.net/browse/JDK-8176451 -Aleksey From rkennke at redhat.com Mon Mar 13 17:48:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 13 Mar 2017 18:48:13 +0100 Subject: RFR: Partial GC Message-ID: This implements a skeleton partial GC. Skeleton meaning it seems to work for most stuff I throw at it, but is totally not optimized (not even benchmarked) yet. The heuristics also require more through. Currently the partial GC is started whenever ShenandoahAllocationThreshold percent of heap capacity have been allocated since last GC (partial or full). It then selects all regions that have <= ShenandoahPartialInboundThreshold direct root regions into the collection set. The direct inbound regions of the cset regions form the (new) root region set. Partial GC is implemented fully stop-the-world for now. Each GC thread first scans GC roots (threads, etc), then goes on to scan root regions, and, interleaved with that, completes the closure by processing its local task queue. No work stealing for now. (should be easy to do...) Partial GC performs no concurrent GC for now. In order to do this, we'd need eager updating of references (so that we don't have any from-space refs when entering partial GC), or a way to deal with from-space refs during partial-GC/matrix-bookkeeping. Partial GC is activated by -XX:ShenandoahGCHeuristics=partial. What do you think? Ok to push? http://cr.openjdk.java.net/~rkennke/partialgc/webrev.01/ Roman From shade at redhat.com Mon Mar 13 18:04:00 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 19:04:00 +0100 Subject: RFR: Partial GC In-Reply-To: References: Message-ID: <403ff91c-debd-eb10-e192-895d79a6b327@redhat.com> On 03/13/2017 06:48 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/partialgc/webrev.01/ shenandoahCollectorPolicy.cpp: *) Just return? 682 if ((used - _bytes_allocated_after_last_gc) * 100 / capacity > ShenandoahAllocationThreshold) { 683 return true; 684 } else { 685 return false; 686 } shenandoahMarkCompact.cpp: *) VerifyShenandoahMatrix invocation is gone? vm_operations_shenandoah.hpp *) Double new line ;) 85 86 vm_operations.hpp *) Bad indent: 103 template(ShenandoahPartialGC) \ Otherwise OK to go. -Aleksey From rkennke at redhat.com Mon Mar 13 18:30:23 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 13 Mar 2017 19:30:23 +0100 Subject: RFR: Partial GC In-Reply-To: <403ff91c-debd-eb10-e192-895d79a6b327@redhat.com> References: <403ff91c-debd-eb10-e192-895d79a6b327@redhat.com> Message-ID: <12c9915c-b84f-c976-b142-83d2657e5a3f@redhat.com> Am 13.03.2017 um 19:04 schrieb Aleksey Shipilev: > On 03/13/2017 06:48 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/partialgc/webrev.01/ > shenandoahCollectorPolicy.cpp: > > *) Just return? > > 682 if ((used - _bytes_allocated_after_last_gc) * 100 / capacity > > ShenandoahAllocationThreshold) { > 683 return true; > 684 } else { > 685 return false; > 686 } > > shenandoahMarkCompact.cpp: > > *) VerifyShenandoahMatrix invocation is gone? > > vm_operations_shenandoah.hpp > > *) Double new line ;) > 85 > 86 > > vm_operations.hpp > > *) Bad indent: > 103 template(ShenandoahPartialGC) \ > > Otherwise OK to go. > > -Aleksey > Fixed everything except verification in full-gc. We can't really verify the matrix there because at no point during full-GC does the marking bitmap match the new addresses of objects, and therefore the new matrix. This is why I removed it. http://cr.openjdk.java.net/~rkennke/partialgc/webrev.02/ I found the the C2 matrix math optimization broke matrix updating. In order for partial gc to work correctly we either need to back that out or run without C2. Roman From shade at redhat.com Mon Mar 13 18:33:17 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 19:33:17 +0100 Subject: RFR: Partial GC In-Reply-To: <12c9915c-b84f-c976-b142-83d2657e5a3f@redhat.com> References: <403ff91c-debd-eb10-e192-895d79a6b327@redhat.com> <12c9915c-b84f-c976-b142-83d2657e5a3f@redhat.com> Message-ID: On 03/13/2017 07:30 PM, Roman Kennke wrote: > Fixed everything except verification in full-gc. We can't really verify > the matrix there because at no point during full-GC does the marking > bitmap match the new addresses of objects, and therefore the new matrix. > This is why I removed it. > > http://cr.openjdk.java.net/~rkennke/partialgc/webrev.02/ Ok then. > I found the the C2 matrix math optimization broke matrix updating. In > order for partial gc to work correctly we either need to back that out > or run without C2. I would prefer to push this, and then figure out C2. Matrix stuff is under construction anyway, and does not affect default operation. Thanks, -Aleksey From shade at redhat.com Mon Mar 13 19:12:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 20:12:50 +0100 Subject: RFR (XS): Use actual byte value instead of (int)true in C1 matrix barrier Message-ID: <5ad7c361-6909-ce82-8a59-44fa42367969@redhat.com> Found one left-over from bool->char switch: $ hg diff diff -r cba65b85b10c src/share/vm/c1/c1_LIRGenerator.cpp --- a/src/share/vm/c1/c1_LIRGenerator.cpp Mon Mar 13 13:14:37 2017 +0100 +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Mar 13 20:10:30 2017 +0100 @@ -1688,7 +1688,7 @@ __ move(matrix_elem_addr, tmp5); __ cmp(lir_cond_notEqual, tmp5, LIR_OprFact::intConst(0)); __ branch(lir_cond_notEqual, T_BYTE, L_done->label()); - __ move(LIR_OprFact::intConst((int) true), matrix_elem_addr); + __ move(LIR_OprFact::intConst(1), matrix_elem_addr); __ branch_destination(L_done->label()); } Current code should be safe under C++ rules, but better to be safe. Thanks, -Aleksey From zgu at redhat.com Mon Mar 13 19:43:05 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 13 Mar 2017 15:43:05 -0400 Subject: RFR (XS): Use actual byte value instead of (int)true in C1 matrix barrier In-Reply-To: <5ad7c361-6909-ce82-8a59-44fa42367969@redhat.com> References: <5ad7c361-6909-ce82-8a59-44fa42367969@redhat.com> Message-ID: <26827fe8-93fa-65bb-d80f-c96a34726269@redhat.com> +void MacroAssembler::testbool(Address dst) { + if(sizeof(bool) == 1) { + testb(dst, 0xff); + } else { + // unsupported + ShouldNotReachHere(); + } +} Also a left-over? Thanks, -Zhengyu On 03/13/2017 03:12 PM, Aleksey Shipilev wrote: > Found one left-over from bool->char switch: > > $ hg diff > diff -r cba65b85b10c src/share/vm/c1/c1_LIRGenerator.cpp > --- a/src/share/vm/c1/c1_LIRGenerator.cpp Mon Mar 13 13:14:37 2017 +0100 > +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Mar 13 20:10:30 2017 +0100 > @@ -1688,7 +1688,7 @@ > __ move(matrix_elem_addr, tmp5); > __ cmp(lir_cond_notEqual, tmp5, LIR_OprFact::intConst(0)); > __ branch(lir_cond_notEqual, T_BYTE, L_done->label()); > - __ move(LIR_OprFact::intConst((int) true), matrix_elem_addr); > + __ move(LIR_OprFact::intConst(1), matrix_elem_addr); > __ branch_destination(L_done->label()); > } > > Current code should be safe under C++ rules, but better to be safe. > > Thanks, > -Aleksey > From shade at redhat.com Mon Mar 13 21:54:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Mar 2017 22:54:11 +0100 Subject: RFR (XS): Use actual byte value instead of (int)true in C1 matrix barrier In-Reply-To: <26827fe8-93fa-65bb-d80f-c96a34726269@redhat.com> References: <5ad7c361-6909-ce82-8a59-44fa42367969@redhat.com> <26827fe8-93fa-65bb-d80f-c96a34726269@redhat.com> Message-ID: <4ab91ed9-2c20-28ad-43c3-f06c5501edb3@redhat.com> On 03/13/2017 08:43 PM, Zhengyu Gu wrote: > +void MacroAssembler::testbool(Address dst) { > + if(sizeof(bool) == 1) { > + testb(dst, 0xff); > + } else { > + // unsupported > + ShouldNotReachHere(); > + } > +} > > > Also a left-over? Yes! Forgot about that, let's purge that too: http://cr.openjdk.java.net/~shade/shenandoah/matrix-cleanup/webrev.01/ Thanks, -Aleksey From roman at kennke.org Mon Mar 13 22:44:40 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 13 Mar 2017 22:44:40 +0000 Subject: hg: shenandoah/jdk9/hotspot: Partial GC Message-ID: <201703132244.v2DMiewp000907@aojmv0008.oracle.com> Changeset: 48e1bf8fae32 Author: rkennke Date: 2017-03-13 23:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/48e1bf8fae32 Partial GC ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp + src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp + src/share/vm/gc/shenandoah/shenandoahPartialGC.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.hpp ! src/share/vm/runtime/vm_operations.hpp From rkennke at redhat.com Mon Mar 13 22:47:14 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 13 Mar 2017 23:47:14 +0100 Subject: RFR: Partial GC In-Reply-To: References: <403ff91c-debd-eb10-e192-895d79a6b327@redhat.com> <12c9915c-b84f-c976-b142-83d2657e5a3f@redhat.com> Message-ID: Am 13.03.2017 um 19:33 schrieb Aleksey Shipilev: > On 03/13/2017 07:30 PM, Roman Kennke wrote: >> Fixed everything except verification in full-gc. We can't really verify >> the matrix there because at no point during full-GC does the marking >> bitmap match the new addresses of objects, and therefore the new matrix. >> This is why I removed it. >> >> http://cr.openjdk.java.net/~rkennke/partialgc/webrev.02/ > Ok then. > >> I found the the C2 matrix math optimization broke matrix updating. In >> order for partial gc to work correctly we either need to back that out >> or run without C2. > I would prefer to push this, and then figure out C2. Matrix stuff is under > construction anyway, and does not affect default operation. > Have committed+pushed it. You'll noticed that -Xlog:gc+ergo shows zero regions in collection set and therefore root set. Without patch "Shenandoah matrix update barriers should be conditional." you should get a few regions. If you also print out num_incoming in ShenandoahPartialGC::prepare() you'll see that without the patch many regions get a fairly low number of regions (around 10) while with that patch, most are 100 or more, peaking out at many 100s. Just to get us on the same page, I'm running like this: ./build/linux-x86_64-normal-server-release/images/jdk/bin/java -Xlog:gc -Xlog:gc+ergo=debug -XX:ShenandoahGCHeuristics=partial -Xms8g -Xmx8g -XX:+UseShenandoahGC -XX:ArrayCopyLoadStoreMaxElem=0 -XX:+UseShenandoahMatrix -XX:-UseCompressedOops -jar jmh-specjvm2016.jar -f 0 Roman From shade at redhat.com Tue Mar 14 00:04:23 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Mar 2017 01:04:23 +0100 Subject: RFR: Partial GC In-Reply-To: References: <403ff91c-debd-eb10-e192-895d79a6b327@redhat.com> <12c9915c-b84f-c976-b142-83d2657e5a3f@redhat.com> Message-ID: On 03/13/2017 11:47 PM, Roman Kennke wrote: > Am 13.03.2017 um 19:33 schrieb Aleksey Shipilev: >> On 03/13/2017 07:30 PM, Roman Kennke wrote: >>> Fixed everything except verification in full-gc. We can't really verify >>> the matrix there because at no point during full-GC does the marking >>> bitmap match the new addresses of objects, and therefore the new matrix. >>> This is why I removed it. >>> >>> http://cr.openjdk.java.net/~rkennke/partialgc/webrev.02/ >> Ok then. >> >>> I found the the C2 matrix math optimization broke matrix updating. In >>> order for partial gc to work correctly we either need to back that out >>> or run without C2. >> I would prefer to push this, and then figure out C2. Matrix stuff is under >> construction anyway, and does not affect default operation. >> > Have committed+pushed it. > > You'll noticed that -Xlog:gc+ergo shows zero regions in collection set > and therefore root set. Without patch "Shenandoah matrix update barriers > should be conditional." you should get a few regions. If you also print > out num_incoming in ShenandoahPartialGC::prepare() you'll see that > without the patch many regions get a fairly low number of regions > (around 10) while with that patch, most are 100 or more, peaking out at > many 100s. > > Just to get us on the same page, I'm running like this: > > ./build/linux-x86_64-normal-server-release/images/jdk/bin/java -Xlog:gc > -Xlog:gc+ergo=debug -XX:ShenandoahGCHeuristics=partial -Xms8g -Xmx8g > -XX:+UseShenandoahGC -XX:ArrayCopyLoadStoreMaxElem=0 > -XX:+UseShenandoahMatrix -XX:-UseCompressedOops -jar > jmh-specjvm2016.jar -f 0 I'll take a look at C2 code. But what I notice when adding -XX:TieredStopAtLevel=1 there is that we SEGV in the C1 generated code! # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fcae452465c, pid=4467, tid=4499 # # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-adhoc.shade.shenandoah-jdk9) # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.shade.shenandoah-jdk9, mixed mode, tiered, Shenandoah gc, linux-amd64) # Problematic frame: # J 1890 c1 com.sun.tools.javac.util.AbstractLog.getSource(Ljavax/tools/JavaFileObject;)Lcom/sun/tools/javac/util/DiagnosticSource; jdk.compiler at 9-internal (50 bytes) @ 0x00007fcae452465c [0x00007fcae45245e0+0x000000000000007c] The same SEGV happens when I remove the conditionals from assembler/C1 stubs: diff -r 48e1bf8fae32 src/cpu/x86/vm/macroAssembler_x86.cpp --- a/src/cpu/x86/vm/macroAssembler_x86.cpp Mon Mar 13 23:43:23 2017 +0100 +++ b/src/cpu/x86/vm/macroAssembler_x86.cpp Tue Mar 14 00:58:45 2017 +0100 @@ -5381,10 +5381,7 @@ addq(tmp, tmp2); // Address is _matrix[from * stride + to] movptr(rscratch1, (intptr_t) matrix_addr); - // Test if the element is already set. - testb(Address(rscratch1, tmp, Address::times_1), 0); - jcc(Assembler::notZero, done); - // Store true, if not yet set. + // Store true. movb(Address(rscratch1, tmp, Address::times_1), 1); bind(done); } diff -r 48e1bf8fae32 src/share/vm/c1/c1_LIRGenerator.cpp --- a/src/share/vm/c1/c1_LIRGenerator.cpp Mon Mar 13 23:43:23 2017 +0100 +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Tue Mar 14 00:58:45 2017 +0100 @@ -1684,10 +1684,6 @@ __ move(LIR_OprFact::intptrConst((intptr_t) matrix->matrix_addr()), tmp4); LIR_Address* matrix_elem_addr = new LIR_Address(tmp4, tmp1, T_BYTE); - LIR_Opr tmp5 = new_register(T_INT); - __ move(matrix_elem_addr, tmp5); - __ cmp(lir_cond_notEqual, tmp5, LIR_OprFact::intConst(0)); - __ branch(lir_cond_notEqual, T_BYTE, L_done->label()); __ move(LIR_OprFact::intConst((int) true), matrix_elem_addr); __ branch_destination(L_done->label()); } This kinda tells me partial collections mess up the heap? If so, I wouldn't be surprised about ergonomics surprises. Thanks, -Aleksey From rkennke at redhat.com Tue Mar 14 09:56:16 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Mar 2017 10:56:16 +0100 Subject: RFR (XS): Use actual byte value instead of (int)true in C1 matrix barrier In-Reply-To: <4ab91ed9-2c20-28ad-43c3-f06c5501edb3@redhat.com> References: <5ad7c361-6909-ce82-8a59-44fa42367969@redhat.com> <26827fe8-93fa-65bb-d80f-c96a34726269@redhat.com> <4ab91ed9-2c20-28ad-43c3-f06c5501edb3@redhat.com> Message-ID: <7363b354-a8bf-bda1-11cb-aa6c1c22c3b1@redhat.com> Am 13.03.2017 um 22:54 schrieb Aleksey Shipilev: > On 03/13/2017 08:43 PM, Zhengyu Gu wrote: >> +void MacroAssembler::testbool(Address dst) { >> + if(sizeof(bool) == 1) { >> + testb(dst, 0xff); >> + } else { >> + // unsupported >> + ShouldNotReachHere(); >> + } >> +} >> >> >> Also a left-over? > Yes! Forgot about that, let's purge that too: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-cleanup/webrev.01/ Ok! Roman From ashipile at redhat.com Tue Mar 14 10:09:46 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 14 Mar 2017 10:09:46 +0000 Subject: hg: shenandoah/jdk9/hotspot: Matrix barrier bool->char conversion leftovers. Message-ID: <201703141009.v2EA9kKa023769@aojmv0008.oracle.com> Changeset: 99d1d76141e7 Author: shade Date: 2017-03-14 11:09 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/99d1d76141e7 Matrix barrier bool->char conversion leftovers. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp From shade at redhat.com Tue Mar 14 12:05:09 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Mar 2017 13:05:09 +0100 Subject: RFR (XS): C2: Missing matrix update for getAndSet intrinsic Message-ID: Hi, getAndSet jcstress tests like tests.atomicity.varHandles.fields.GetAndSetTest.GetAndSetString are failing with +ShenandoahMatrix. The failure goes like this: for current barrier set, can_move_pre_barrier is true. Which moves the pre_barrier *after* the store, which then misses newval, because pre_barrier is called with NULL! The easiest fix is to avoid moving pre_barriers when matrix update is in order: http://cr.openjdk.java.net/~shade/shenandoah/matrix-getandset/webrev.01/ I failed to create a standalone reproducer, but jcstress seems happy now. Testing: hotspot_gc_shenandoah, offending jcstress tests Thanks, -Aleksey From rkennke at redhat.com Tue Mar 14 12:55:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Mar 2017 13:55:21 +0100 Subject: RFR (XS): C2: Missing matrix update for getAndSet intrinsic In-Reply-To: References: Message-ID: Am 14.03.2017 um 13:05 schrieb Aleksey Shipilev: > Hi, > > getAndSet jcstress tests like > tests.atomicity.varHandles.fields.GetAndSetTest.GetAndSetString are failing with > +ShenandoahMatrix. > > The failure goes like this: for current barrier set, can_move_pre_barrier is > true. Which moves the pre_barrier *after* the store, which then misses newval, > because pre_barrier is called with NULL! > > The easiest fix is to avoid moving pre_barriers when matrix update is in order: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-getandset/webrev.01/ > > I failed to create a standalone reproducer, but jcstress seems happy now. > > Testing: hotspot_gc_shenandoah, offending jcstress tests > > Thanks, > -Aleksey > It might be better to simply call it with newval != NULL. I suspect that blocking can_move_pre_barrier() might prevent some optimizations, for example, getAndSet() pre-barrier doesn't actually need to load the pre-value when executed after the fact. And it also affects other intrinsics than getAndSet(). IIRC from my i-u work (where I also changed all the pre-barriers to get called with newval != NULL), there is an asserts in the g1 pre-barrier code that will complain when do_load == false and newval != NULL, but otherwise it should have no negative effect. Roman From shade at redhat.com Tue Mar 14 13:56:32 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Mar 2017 14:56:32 +0100 Subject: RFR (XS): C2: Missing matrix update for getAndSet intrinsic In-Reply-To: References: Message-ID: <21680109-21d6-2550-dbec-5257a54c52f7@redhat.com> On 03/14/2017 01:55 PM, Roman Kennke wrote: > It might be better to simply call it with newval != NULL. I suspect that > blocking can_move_pre_barrier() might prevent some optimizations, for > example, getAndSet() pre-barrier doesn't actually need to load the > pre-value when executed after the fact. I thought so too, but when I change the "moved" pre_barrier to accept new_val, it crashes on other asserts within C2 (f.ex. split-if barfs at graph shape). Doing this, basically: diff -r 99d1d76141e7 src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Tue Mar 14 11:09:03 2017 +0100 +++ b/src/share/vm/opto/library_call.cpp Tue Mar 14 14:55:51 2017 +0100 @@ -3115,12 +3115,12 @@ load_store = _gvn.transform(new DecodeNNode(load_store, load_store->get_ptr_type())); } #endif - if (can_move_pre_barrier()) { + if (can_move_pre_barrier() && kind == LS_get_set) { // Don't need to load pre_val. The old value is returned by load_store. // The pre_barrier can execute after the xchg as long as no safepoint // gets inserted between them. pre_barrier(false /* do_load */, - control(), NULL, NULL, max_juint, NULL, NULL, + control(), NULL, adr, max_juint, newval, NULL, load_store /* pre_val */, T_OBJECT); } Yields: # Internal Error (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/opto/split_if.cpp:287), pid=30197, tid=30218 # assert(prior_n->is_Region()) failed: must be a post-dominating merge point > And it also affects other intrinsics than getAndSet(). Really? can_move_pre_barrier() only affects LS_get_set, as far as I can see. Thanks, -Aleksey From rkennke at redhat.com Tue Mar 14 14:09:15 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Mar 2017 15:09:15 +0100 Subject: RFR (XS): C2: Missing matrix update for getAndSet intrinsic In-Reply-To: <21680109-21d6-2550-dbec-5257a54c52f7@redhat.com> References: <21680109-21d6-2550-dbec-5257a54c52f7@redhat.com> Message-ID: <87fd78a1-51f9-cd7c-0e7e-69101bf0c028@redhat.com> Am 14.03.2017 um 14:56 schrieb Aleksey Shipilev: > On 03/14/2017 01:55 PM, Roman Kennke wrote: >> It might be better to simply call it with newval != NULL. I suspect that >> blocking can_move_pre_barrier() might prevent some optimizations, for >> example, getAndSet() pre-barrier doesn't actually need to load the >> pre-value when executed after the fact. > I thought so too, but when I change the "moved" pre_barrier to accept new_val, > it crashes on other asserts within C2 (f.ex. split-if barfs at graph shape). > Doing this, basically: > > diff -r 99d1d76141e7 src/share/vm/opto/library_call.cpp > --- a/src/share/vm/opto/library_call.cpp Tue Mar 14 11:09:03 2017 +0100 > +++ b/src/share/vm/opto/library_call.cpp Tue Mar 14 14:55:51 2017 +0100 > @@ -3115,12 +3115,12 @@ > load_store = _gvn.transform(new DecodeNNode(load_store, > load_store->get_ptr_type())); > } > #endif > - if (can_move_pre_barrier()) { > + if (can_move_pre_barrier() && kind == LS_get_set) { > // Don't need to load pre_val. The old value is returned by load_store. > // The pre_barrier can execute after the xchg as long as no safepoint > // gets inserted between them. > pre_barrier(false /* do_load */, > - control(), NULL, NULL, max_juint, NULL, NULL, > + control(), NULL, adr, max_juint, newval, NULL, > load_store /* pre_val */, > T_OBJECT); > } > > Yields: > > # Internal Error > (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/opto/split_if.cpp:287), > pid=30197, tid=30218 > # assert(prior_n->is_Region()) failed: must be a post-dominating merge point Grrrr!! To be honest, there's no code path that usually returns false on can_move_pre_barrier(). IMO, this should go to the trash bin. >> And it also affects other intrinsics than getAndSet(). > Really? can_move_pre_barrier() only affects LS_get_set, as far as I can see. I thought it also affects cas intrinsics. Must be a bad memory. :-P Push it as-is, and also push it to Roland's to-do list? :-) Roman From ashipile at redhat.com Tue Mar 14 14:15:15 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 14 Mar 2017 14:15:15 +0000 Subject: hg: shenandoah/jdk9/hotspot: C2: Missing matrix update for getAndSet intrinsic. Message-ID: <201703141415.v2EEFFuH009764@aojmv0008.oracle.com> Changeset: 7aa6f51f0635 Author: shade Date: 2017-03-14 15:12 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/7aa6f51f0635 C2: Missing matrix update for getAndSet intrinsic. ! src/share/vm/opto/graphKit.cpp From shade at redhat.com Tue Mar 14 14:19:31 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Mar 2017 15:19:31 +0100 Subject: C2, pre-barrier, getAndSet Message-ID: <3b7a0a83-2bc2-8278-0949-116c9f8e9c82@redhat.com> Here is the failure: $ ~/trunks/shenandoah-jdk9/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:+UseShenandoahMatrix -XX:+VerifyShenandoahMatrix -jar tests-all/target/jcstress.jar -t org.openjdk.jcstress.tests.atomicity.varHandles.fields.GetAndSetTest.GetAndSetString # Internal Error (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/opto/split_if.cpp:287), pid=10961, tid=10984 # assert(prior_n->is_Region()) failed: must be a post-dominating merge point Patches, hs_errs, replays here: http://cr.openjdk.java.net/~shade/shenandoah/wtf-c2-getandset/ Thanks, -Aleksey From rwestrel at redhat.com Wed Mar 15 08:10:29 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 15 Mar 2017 08:10:29 +0000 Subject: hg: shenandoah/jdk9/hotspot: missed barrier elimination opportunity in ShenandoahBarrierNode::try_common() Message-ID: <201703150810.v2F8AUK7010785@aojmv0008.oracle.com> Changeset: bd3f6943b0b5 Author: roland Date: 2017-03-15 08:53 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/bd3f6943b0b5 missed barrier elimination opportunity in ShenandoahBarrierNode::try_common() ! src/share/vm/opto/shenandoahSupport.cpp From rkennke at redhat.com Wed Mar 15 10:10:22 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 15 Mar 2017 11:10:22 +0100 Subject: RFR: Various fixes and improvements for partial GC Message-ID: <5421b5be-5f0c-1a4e-a622-b12875b5d73c@redhat.com> This fixes a number of issues and implements some improvements. In particular: - Most important: when evacuating an oop, we need to not only fix up and update the matrix for pointers into the cset (as we already do), but we also need to update the matrix for pointers outside the cset! - Make sure we don't get overlap between the collection set and the root set. Regions already in the cset don't need to be in the root set. - We're iterating over all root regions: we can just as well cleanup and update the outgoing matrix for them. Makes the matrix more precise. - Make building the root set a bit more efficient: instead of iterating over all regions and picking only cset regions, we can iterate over the cset regions to begin with. Also, instead of using root_regions->contains() for determining whether or not a region is a root (which is a linear search), I added set/is_root() to SHR, and use that. - ShenandoahPartialInboundThreshold doesn't need to be bounded by 0..100 (it's not a percentage) - Added a number of asserts and TODOs http://cr.openjdk.java.net/~rkennke/fixpartialgc/webrev.00/ Ok? Roman From shade at redhat.com Wed Mar 15 10:20:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Mar 2017 11:20:05 +0100 Subject: RFR: Various fixes and improvements for partial GC In-Reply-To: <5421b5be-5f0c-1a4e-a622-b12875b5d73c@redhat.com> References: <5421b5be-5f0c-1a4e-a622-b12875b5d73c@redhat.com> Message-ID: On 03/15/2017 11:10 AM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/fixpartialgc/webrev.00/ Okay! -Aleksey From roman at kennke.org Wed Mar 15 10:21:15 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 15 Mar 2017 10:21:15 +0000 Subject: hg: shenandoah/jdk9/hotspot: Various fixes and improvements for partial GC. Message-ID: <201703151021.v2FALFLe014407@aojmv0008.oracle.com> Changeset: a6169af5e360 Author: rkennke Date: 2017-03-15 11:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a6169af5e360 Various fixes and improvements for partial GC. ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp From shade at redhat.com Wed Mar 15 13:07:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Mar 2017 14:07:50 +0100 Subject: RFR: Heap/matrix verification for all reachable objects Message-ID: <9868fc07-240b-9bd7-58a6-26e7f1b0a64a@redhat.com> Hi, This is the verification code that works by asserting invariants on all _reachable_ objects. This allows to verify both heap and the matrix without having the complete prior mark. Which helps, for example, to assert the matrix validity in partial collections. See: http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-reachable/webrev.01/ Testing: hotspot_gc_shenandoah (fastdebug/release), selected performance workloads Thanks, -Aleksey From rkennke at redhat.com Wed Mar 15 13:11:35 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 15 Mar 2017 14:11:35 +0100 Subject: RFR: Heap/matrix verification for all reachable objects In-Reply-To: <9868fc07-240b-9bd7-58a6-26e7f1b0a64a@redhat.com> References: <9868fc07-240b-9bd7-58a6-26e7f1b0a64a@redhat.com> Message-ID: <6fdfb22f-917c-6a83-4abd-df2980ca4ab8@redhat.com> Am 15.03.2017 um 14:07 schrieb Aleksey Shipilev: > Hi, > > This is the verification code that works by asserting invariants on all > _reachable_ objects. This allows to verify both heap and the matrix without > having the complete prior mark. Which helps, for example, to assert the matrix > validity in partial collections. > > See: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-reachable/webrev.01/ > > Testing: hotspot_gc_shenandoah (fastdebug/release), selected performance workloads > > Thanks, > -Aleksey > Very good! Thanks you! Roman From ashipile at redhat.com Wed Mar 15 13:13:48 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 15 Mar 2017 13:13:48 +0000 Subject: hg: shenandoah/jdk9/hotspot: Heap/matrix verification for all reachable objects. Message-ID: <201703151313.v2FDDmOe006231@aojmv0008.oracle.com> Changeset: e65f4fac6a63 Author: shade Date: 2017-03-15 14:13 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e65f4fac6a63 Heap/matrix verification for all reachable objects. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From zgu at redhat.com Wed Mar 15 13:25:04 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Mar 2017 09:25:04 -0400 Subject: RFR: Heap/matrix verification for all reachable objects In-Reply-To: <9868fc07-240b-9bd7-58a6-26e7f1b0a64a@redhat.com> References: <9868fc07-240b-9bd7-58a6-26e7f1b0a64a@redhat.com> Message-ID: There is a NMT miscounting: ShenandoahHeap.cpp 2021 os::uncommit_memory(bm.base(), bm.size()); 2022 MemTracker::record_free(bm.base()); 2023 delete(q); MemTracker::record_free() is for malloc'd memory. You don't need explicit counting here, os::uncommit_memory does that for you. Thanks, -Zhengyu On 03/15/2017 09:07 AM, Aleksey Shipilev wrote: > Hi, > > This is the verification code that works by asserting invariants on all > _reachable_ objects. This allows to verify both heap and the matrix without > having the complete prior mark. Which helps, for example, to assert the matrix > validity in partial collections. > > See: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-reachable/webrev.01/ > > Testing: hotspot_gc_shenandoah (fastdebug/release), selected performance workloads > > Thanks, > -Aleksey > From ashipile at redhat.com Wed Mar 15 13:29:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 15 Mar 2017 13:29:03 +0000 Subject: hg: shenandoah/jdk9/hotspot: Remove double-counting for NMT, uncommit_memory does it. Message-ID: <201703151329.v2FDT39m010822@aojmv0008.oracle.com> Changeset: ff1dbca887a4 Author: shade Date: 2017-03-15 14:28 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ff1dbca887a4 Remove double-counting for NMT, uncommit_memory does it. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp From shade at redhat.com Wed Mar 15 13:29:19 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Mar 2017 14:29:19 +0100 Subject: RFR: Heap/matrix verification for all reachable objects In-Reply-To: References: <9868fc07-240b-9bd7-58a6-26e7f1b0a64a@redhat.com> Message-ID: <1cf50dca-9342-db1b-ade4-82958fb5aeb3@redhat.com> On 03/15/2017 02:25 PM, Zhengyu Gu wrote: > There is a NMT miscounting: > ShenandoahHeap.cpp > > 2021 os::uncommit_memory(bm.base(), bm.size()); > 2022 MemTracker::record_free(bm.base()); > 2023 delete(q); > > MemTracker::record_free() is for malloc'd memory. You don't need explicit > counting here, os::uncommit_memory does that for you. Thanks! Removed record_free: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ff1dbca887a4 -Aleksey From shade at redhat.com Wed Mar 15 13:56:20 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Mar 2017 14:56:20 +0100 Subject: RFR (XS): Bad shift coalescing in C2 matrix update barrier Message-ID: <605d6bd8-0d45-6e98-b04d-73d4e7e6daf2@redhat.com> Hi, So I succumbed by Roman's nagging that something is wrong with C2 matrix update barriers, and by staring into the code discovered an absolutely moronic optimization I did there! I assumed: [(x >> A) << B] is [X >> (A-B)] ...but you also need to mask out the lower B bits in the result! Let's remove that optimization: http://cr.openjdk.java.net/~shade/shenandoah/matrix-c2-badshift/webrev.01/ I will figure out separately if shift coalescing + mask is still beneficial. Testing: failing tests with matrix verification Thanks, -Aleksey From rkennke at redhat.com Wed Mar 15 14:01:37 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 15 Mar 2017 15:01:37 +0100 Subject: RFR (XS): Bad shift coalescing in C2 matrix update barrier In-Reply-To: <605d6bd8-0d45-6e98-b04d-73d4e7e6daf2@redhat.com> References: <605d6bd8-0d45-6e98-b04d-73d4e7e6daf2@redhat.com> Message-ID: <78a23735-d532-3215-d98a-312a7eaeb558@redhat.com> Am 15.03.2017 um 14:56 schrieb Aleksey Shipilev: > Hi, > > So I succumbed by Roman's nagging that something is wrong with C2 matrix update > barriers, and by staring into the code discovered an absolutely moronic > optimization I did there! > > I assumed: > [(x >> A) << B] is [X >> (A-B)] > > ...but you also need to mask out the lower B bits in the result! > > Let's remove that optimization: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-c2-badshift/webrev.01/ > > I will figure out separately if shift coalescing + mask is still beneficial. > > Testing: failing tests with matrix verification > > Thanks, > -Aleksey > Go! From ashipile at redhat.com Wed Mar 15 14:02:56 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 15 Mar 2017 14:02:56 +0000 Subject: hg: shenandoah/jdk9/hotspot: Bad shift coalescing in C2 matrix update barrier. Message-ID: <201703151402.v2FE2v4B021486@aojmv0008.oracle.com> Changeset: 27da83b58dcd Author: shade Date: 2017-03-15 15:02 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/27da83b58dcd Bad shift coalescing in C2 matrix update barrier. ! src/share/vm/opto/graphKit.cpp From rkennke at redhat.com Wed Mar 15 16:18:04 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 15 Mar 2017 17:18:04 +0100 Subject: RFR: Add stats for partial GC Message-ID: <08ded171-5fde-314c-74bf-ceea3a464cf5@redhat.com> As $SUBJECT says. http://cr.openjdk.java.net/~rkennke/partial-stats/webrev.00/ Roman From shade at redhat.com Wed Mar 15 16:19:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Mar 2017 17:19:50 +0100 Subject: RFR: Add stats for partial GC In-Reply-To: <08ded171-5fde-314c-74bf-ceea3a464cf5@redhat.com> References: <08ded171-5fde-314c-74bf-ceea3a464cf5@redhat.com> Message-ID: On 03/15/2017 05:18 PM, Roman Kennke wrote: > As $SUBJECT says. > > http://cr.openjdk.java.net/~rkennke/partial-stats/webrev.00/ Bad indent: 774 _phase_names[partial_gc] = "Partial GC"; Otherwise good. -Aleksey From roman at kennke.org Wed Mar 15 16:21:37 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 15 Mar 2017 16:21:37 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add stats for partial GC. Message-ID: <201703151621.v2FGLbFY007217@aojmv0008.oracle.com> Changeset: baadff64fa6d Author: rkennke Date: 2017-03-15 17:20 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/baadff64fa6d Add stats for partial GC. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From shade at redhat.com Thu Mar 16 10:22:43 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Mar 2017 11:22:43 +0100 Subject: RFR (S): Verification code, memory management assert fixes Message-ID: <8d7d1473-404c-4d47-f99c-bf56aa241b49@redhat.com> Hi, Current fastdebug with matrix verification fails like this: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/memory/operator_new.cpp:65), pid=2118, tid=2140 # fatal error: Should not call global operator new This is because CMBitMap is not CHeapObj, and should not be allocated with new, otherwise it allegedly leaks memory. Changed to stack alloc. The bitmap contents are still allocated in memory region outside of stack. Then it will fail with: # Internal Error (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/gc/shared/taskqueue.inline.hpp:52), pid=5302, tid=5328 # assert(false) failed: This code is currently never called Because there is assert(false) in GTQ destructor! Fixed both: http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-cleanups/webrev.01/ Testing: failing tests. Thanks, -Aleksey From rkennke at redhat.com Thu Mar 16 10:25:35 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Mar 2017 11:25:35 +0100 Subject: RFR (S): Verification code, memory management assert fixes In-Reply-To: <8d7d1473-404c-4d47-f99c-bf56aa241b49@redhat.com> References: <8d7d1473-404c-4d47-f99c-bf56aa241b49@redhat.com> Message-ID: Am 16.03.2017 um 11:22 schrieb Aleksey Shipilev: > Hi, > > Current fastdebug with matrix verification fails like this: > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/memory/operator_new.cpp:65), > pid=2118, tid=2140 > # fatal error: Should not call global operator new > > This is because CMBitMap is not CHeapObj, and should not be allocated with new, > otherwise it allegedly leaks memory. Changed to stack alloc. The bitmap contents > are still allocated in memory region outside of stack. > > Then it will fail with: > > # Internal Error > (/home/shade/trunks/shenandoah-jdk9/hotspot/src/share/vm/gc/shared/taskqueue.inline.hpp:52), > pid=5302, tid=5328 > # assert(false) failed: This code is currently never called > > Because there is assert(false) in GTQ destructor! > > Fixed both: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-cleanups/webrev.01/ > > Testing: failing tests. > > Thanks, > -Aleksey > Yes! Roman From ashipile at redhat.com Thu Mar 16 10:27:49 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 16 Mar 2017 10:27:49 +0000 Subject: hg: shenandoah/jdk9/hotspot: Verification code, memory management assert fixes. Message-ID: <201703161027.v2GARoN9013551@aojmv0008.oracle.com> Changeset: 43bf7643ed2a Author: shade Date: 2017-03-16 11:27 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/43bf7643ed2a Verification code, memory management assert fixes. ! src/share/vm/gc/shared/taskqueue.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp From rwestrel at redhat.com Thu Mar 16 12:04:36 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 16 Mar 2017 12:04:36 +0000 Subject: hg: shenandoah/jdk9/hotspot: matrix update and unsafe load store fix Message-ID: <201703161204.v2GC4a8f016179@aojmv0008.oracle.com> Changeset: 366a99d8bd1b Author: roland Date: 2017-03-16 12:52 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/366a99d8bd1b matrix update and unsafe load store fix ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp From rkennke at redhat.com Thu Mar 16 13:10:00 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Mar 2017 14:10:00 +0100 Subject: RFR: Add humongous regions support to partial GC Message-ID: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> This adds support for humongous regions as root regions in partial GC. I extended the ShenandoahHeapRegion::oop_iterate() to iterate over a subset of a humongous object array (bounded by the region). This way we avoid scanning the whole humongous object if the matrix only gives us a single region as root. Tested using gc-bench/arrayfragger (which crashed before). http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.00/ Roman From shade at redhat.com Thu Mar 16 13:26:02 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Mar 2017 14:26:02 +0100 Subject: RFR: Add humongous regions support to partial GC In-Reply-To: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> References: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> Message-ID: On 03/16/2017 02:10 PM, Roman Kennke wrote: > This adds support for humongous regions as root regions in partial GC. > > I extended the ShenandoahHeapRegion::oop_iterate() to iterate over a > subset of a humongous object array (bounded by the region). This way we > avoid scanning the whole humongous object if the matrix only gives us a > single region as root. > > Tested using gc-bench/arrayfragger (which crashed before). > > http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.00/ Um. *) I am blind! Who sets humongous_obj_array? *) There is a weird disconnect: assume we call oop_iterate on a humongous region *head*. With primitive array, it would touch the array oop. With object array, it would only touch the array contents? -Aleksey From rkennke at redhat.com Thu Mar 16 14:48:54 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Mar 2017 15:48:54 +0100 Subject: RFR: Add humongous regions support to partial GC In-Reply-To: References: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> Message-ID: <7620b0a5-a17f-4038-48ce-aeac41e4f1e9@redhat.com> Am 16.03.2017 um 14:26 schrieb Aleksey Shipilev: > On 03/16/2017 02:10 PM, Roman Kennke wrote: >> This adds support for humongous regions as root regions in partial GC. >> >> I extended the ShenandoahHeapRegion::oop_iterate() to iterate over a >> subset of a humongous object array (bounded by the region). This way we >> avoid scanning the whole humongous object if the matrix only gives us a >> single region as root. >> >> Tested using gc-bench/arrayfragger (which crashed before). >> >> http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.00/ > Um. > > *) I am blind! Who sets humongous_obj_array? Ugh. I mixed up some stuff... I originally wanted to do it another way, but now realize we don't even need to differentiate between obj and primitive arrays. We can simply rewind to the head, call oop_iterate() with a region, and let the implementation in oops sort it out. I.e. for primitive arrays it would be a no-op (plus header), for oop arrays it would do the right thing. This simplifies the patch. > *) There is a weird disconnect: assume we call oop_iterate on a humongous > region *head*. With primitive array, it would touch the array oop. With object > array, it would only touch the array contents? The oop_iterate() implementation *always* visits the header, no matter which region it iterates over. This might be overkill, but is conservative. For partial-GC it currently doesn't matter, as we don't traverse through the header. http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.01/ Roman From shade at redhat.com Thu Mar 16 14:56:04 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Mar 2017 15:56:04 +0100 Subject: RFR: Add humongous regions support to partial GC In-Reply-To: <7620b0a5-a17f-4038-48ce-aeac41e4f1e9@redhat.com> References: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> <7620b0a5-a17f-4038-48ce-aeac41e4f1e9@redhat.com> Message-ID: On 03/16/2017 03:48 PM, Roman Kennke wrote: > Am 16.03.2017 um 14:26 schrieb Aleksey Shipilev: >> On 03/16/2017 02:10 PM, Roman Kennke wrote: >>> This adds support for humongous regions as root regions in partial GC. >>> >>> I extended the ShenandoahHeapRegion::oop_iterate() to iterate over a >>> subset of a humongous object array (bounded by the region). This way we >>> avoid scanning the whole humongous object if the matrix only gives us a >>> single region as root. >>> >>> Tested using gc-bench/arrayfragger (which crashed before). >>> >>> http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.00/ >> Um. >> >> *) I am blind! Who sets humongous_obj_array? > > Ugh. I mixed up some stuff... I originally wanted to do it another way, > but now realize we don't even need to differentiate between obj and > primitive arrays. We can simply rewind to the head, call oop_iterate() > with a region, and let the implementation in oops sort it out. I.e. for > primitive arrays it would be a no-op (plus header), for oop arrays it > would do the right thing. This simplifies the patch. >> *) There is a weird disconnect: assume we call oop_iterate on a humongous >> region *head*. With primitive array, it would touch the array oop. With object >> array, it would only touch the array contents? > > The oop_iterate() implementation *always* visits the header, no matter > which region it iterates over. This might be overkill, but is > conservative. For partial-GC it currently doesn't matter, as we don't > traverse through the header. > > http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.01/ Ok, this one makes sense. Thanks, -Aleksey From roman at kennke.org Thu Mar 16 15:19:07 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 16 Mar 2017 15:19:07 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add humongous regions support to partial GC. Message-ID: <201703161519.v2GFJ7bX011154@aojmv0008.oracle.com> Changeset: b35e273953d4 Author: rkennke Date: 2017-03-16 14:36 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/b35e273953d4 Add humongous regions support to partial GC. ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From zgu at redhat.com Thu Mar 16 15:25:56 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Mar 2017 11:25:56 -0400 Subject: RFR: Add humongous regions support to partial GC In-Reply-To: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> References: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> Message-ID: <1bf13852-960f-4baa-5817-a33b4f910cbd@redhat.com> Do you really need _humongous_obj_array? should is_humongous() enough to indicate that? Thanks, -Zhengyu On 03/16/2017 09:10 AM, Roman Kennke wrote: > This adds support for humongous regions as root regions in partial GC. > > I extended the ShenandoahHeapRegion::oop_iterate() to iterate over a > subset of a humongous object array (bounded by the region). This way we > avoid scanning the whole humongous object if the matrix only gives us a > single region as root. > > Tested using gc-bench/arrayfragger (which crashed before). > > http://cr.openjdk.java.net/~rkennke/partial-humongous/webrev.00/ > > > Roman > > From rkennke at redhat.com Thu Mar 16 16:04:04 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Mar 2017 17:04:04 +0100 Subject: RFR: Add humongous regions support to partial GC In-Reply-To: <1bf13852-960f-4baa-5817-a33b4f910cbd@redhat.com> References: <72fc6fd8-e27b-1e2f-1494-ff40ced9065f@redhat.com> <1bf13852-960f-4baa-5817-a33b4f910cbd@redhat.com> Message-ID: Am 16.03.2017 um 16:25 schrieb Zhengyu Gu: > Do you really need _humongous_obj_array? should is_humongous() enough > to indicate that? Yes. The final patch that I pushed removed that part. :-) Roman From rwestrel at redhat.com Thu Mar 16 16:50:03 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 16 Mar 2017 16:50:03 +0000 Subject: hg: shenandoah/jdk9/hotspot: enable small array copy optimization when no oop is copied Message-ID: <201703161650.v2GGo36f008381@aojmv0008.oracle.com> Changeset: cf41c9d0aecb Author: roland Date: 2017-03-16 17:48 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/cf41c9d0aecb enable small array copy optimization when no oop is copied ! src/share/vm/opto/arraycopynode.cpp ! src/share/vm/runtime/arguments.cpp From rkennke at redhat.com Thu Mar 16 17:44:54 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Mar 2017 18:44:54 +0100 Subject: RFR: Partial GC: Only evacuating threads push oop to work queue Message-ID: <06f6217c-8526-3cb5-fd17-e197b1520c0e@redhat.com> Currently, GC threads push evacuated objects to their work queue, no matter whether this or another thread succeeded to evacuate the object. This potentially creates too much work, false sharing, requires 2 CASes (once for the brooks ptr, and once more for updating the ref). This patch makes the thread check whether it was the one who succeeded the evac, and only then push the oop to its task queue. This requires a little refactoring of ShenandoahHeap::evacuate_object() to accept an out param (better ideas welcome!). I also changed to use ordinary store for updating refs. http://cr.openjdk.java.net/~rkennke/partialevacthread/webrev.00/ Baseline: Result "org.openjdk.specjvm2008.Compiler.compiler": 116,958 ?(99.9%) 39,590 ops/min [Average] (min, avg, max) = (87,650, 116,958, 148,328), stdev = 26,186 [282,272s][info][gc,stats] Partial GC = 97,73 s (a = 157883 us) (n = 619) (lvls, us = 66602, 109375, 144531, 189453, 419521) Patched: Result "org.openjdk.specjvm2008.Compiler.compiler": 124,367 ?(99.9%) 42,775 ops/min [Average] (min, avg, max) = (95,156, 124,367, 160,069), stdev = 28,293 [266,515s][info][gc,stats] Partial GC = 74,95 s (a = 119924 us) (n = 625) (lvls, us = 21680, 83984, 113281, 144531, 275657) Roman From shade at redhat.com Thu Mar 16 17:56:15 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Mar 2017 18:56:15 +0100 Subject: RFR: Partial GC: Only evacuating threads push oop to work queue In-Reply-To: <06f6217c-8526-3cb5-fd17-e197b1520c0e@redhat.com> References: <06f6217c-8526-3cb5-fd17-e197b1520c0e@redhat.com> Message-ID: <138126e3-ddda-fecd-c847-1e41cb1293a6@redhat.com> On 03/16/2017 06:44 PM, Roman Kennke wrote: > This patch makes the thread check whether it was the one who succeeded > the evac, and only then push the oop to its task queue. This requires a > little refactoring of ShenandoahHeap::evacuate_object() to accept an out > param (better ideas welcome!). No better ideas. > http://cr.openjdk.java.net/~rkennke/partialevacthread/webrev.00/ Okay! Thanks, -Aleksey From roman at kennke.org Thu Mar 16 18:00:17 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 16 Mar 2017 18:00:17 +0000 Subject: hg: shenandoah/jdk9/hotspot: Partial GC: Only evacuating threads push oop to work queue. Message-ID: <201703161800.v2GI0HmO001146@aojmv0008.oracle.com> Changeset: 01e77b20ac9b Author: rkennke Date: 2017-03-16 18:38 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/01e77b20ac9b Partial GC: Only evacuating threads push oop to work queue. ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From shade at redhat.com Thu Mar 16 18:18:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Mar 2017 19:18:42 +0100 Subject: RFR: Partial GC: Implement work-stealing and rehash queue work Message-ID: Hi, This change implements work-stealing in partial GC. It also *first* processes all roots and root regions to keep threads busy, and *then* dives into queue draining work. Webrev: http://cr.openjdk.java.net/~shade/shenandoah/partial-workstealing/webrev.01/ Testing: hotspot_gc_shenandoah, cursory jcstress -m quick TreeFragger before: [60.209s][info][gc,stats] Partial GC = 24.48 s (a = 844209 us) (n = 29) (lvls, us = 349609, 369141, 445312, 1660156, 1865855) TreeFragger after: [57.090s][info][gc,stats] Partial GC = 8.28 s (a = 201969 us) (n = 41) (lvls, us = 77734, 91211, 138672, 371094, 436511) Thanks, -Aleksey From zgu at redhat.com Thu Mar 16 18:28:36 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Mar 2017 14:28:36 -0400 Subject: RFR: Partial GC: Implement work-stealing and rehash queue work In-Reply-To: References: Message-ID: <27493465-0458-b62e-653a-29508c4c19d2@redhat.com> Can easily add Terminator there, will it make difference? -Zhengyu On 03/16/2017 02:18 PM, Aleksey Shipilev wrote: > Hi, > > This change implements work-stealing in partial GC. It also *first* processes > all roots and root regions to keep threads busy, and *then* dives into queue > draining work. > > Webrev: > http://cr.openjdk.java.net/~shade/shenandoah/partial-workstealing/webrev.01/ > > Testing: hotspot_gc_shenandoah, cursory jcstress -m quick > > TreeFragger before: > [60.209s][info][gc,stats] Partial GC = > 24.48 s (a = 844209 us) (n = 29) > (lvls, us = 349609, 369141, 445312, 1660156, 1865855) > > TreeFragger after: > [57.090s][info][gc,stats] Partial GC = > 8.28 s (a = 201969 us) (n = 41) > (lvls, us = 77734, 91211, 138672, 371094, 436511) > > Thanks, > -Aleksey > From shade at redhat.com Thu Mar 16 18:35:08 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Mar 2017 19:35:08 +0100 Subject: RFR: Partial GC: Implement work-stealing and rehash queue work In-Reply-To: <27493465-0458-b62e-653a-29508c4c19d2@redhat.com> References: <27493465-0458-b62e-653a-29508c4c19d2@redhat.com> Message-ID: <22cbd4f6-3ffe-0839-c742-14bf04190fd2@redhat.com> On 03/16/2017 07:28 PM, Zhengyu Gu wrote: > Can easily add Terminator there, will it make difference? (slaps forehead) Yes, I also forgot about OWST! It does not help on my workload much, but having a terminator makes me more confident about this change: http://cr.openjdk.java.net/~shade/shenandoah/partial-workstealing/webrev.02/ Thanks, -Aleksey From zgu at redhat.com Thu Mar 16 18:42:16 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Mar 2017 14:42:16 -0400 Subject: RFR: Partial GC: Implement work-stealing and rehash queue work In-Reply-To: <22cbd4f6-3ffe-0839-c742-14bf04190fd2@redhat.com> References: <27493465-0458-b62e-653a-29508c4c19d2@redhat.com> <22cbd4f6-3ffe-0839-c742-14bf04190fd2@redhat.com> Message-ID: Good to me. -Zhengyu On 03/16/2017 02:35 PM, Aleksey Shipilev wrote: > On 03/16/2017 07:28 PM, Zhengyu Gu wrote: >> Can easily add Terminator there, will it make difference? > > (slaps forehead) > > Yes, I also forgot about OWST! It does not help on my workload much, but having > a terminator makes me more confident about this change: > http://cr.openjdk.java.net/~shade/shenandoah/partial-workstealing/webrev.02/ > > Thanks, > -Aleksey > From ashipile at redhat.com Thu Mar 16 18:46:43 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 16 Mar 2017 18:46:43 +0000 Subject: hg: shenandoah/jdk9/hotspot: Partial GC: Implement work-stealing and rehash queue work. Message-ID: <201703161846.v2GIkhGP013752@aojmv0008.oracle.com> Changeset: 970faf20170c Author: shade Date: 2017-03-16 19:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/970faf20170c Partial GC: Implement work-stealing and rehash queue work. ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.hpp From shade at redhat.com Fri Mar 17 10:08:54 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 17 Mar 2017 11:08:54 +0100 Subject: RFR (S): Matrix verification leaks reserved memory Message-ID: Hi, Some overnight runs crashed with failure to reserve memory. That's because we leak reserved memory in verification code. The apparent solution is just to reserve/commit the memory once during ShenandoahHeap initialization when verification is enabled: http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-leak/webrev.01/ Testing: hotspot_gc_shenandoah, failing tests Thanks, -Aleksey From rkennke at redhat.com Fri Mar 17 10:16:06 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 17 Mar 2017 11:16:06 +0100 Subject: RFR (S): Matrix verification leaks reserved memory In-Reply-To: References: Message-ID: <76de82a5-80e0-be4a-c800-9d64a89d6ab3@redhat.com> Am 17.03.2017 um 11:08 schrieb Aleksey Shipilev: > Hi, > > Some overnight runs crashed with failure to reserve memory. That's because we > leak reserved memory in verification code. The apparent solution is just to > reserve/commit the memory once during ShenandoahHeap initialization when > verification is enabled: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-verify-leak/webrev.01/ > > Testing: hotspot_gc_shenandoah, failing tests > > Thanks, > -Aleksey > Ok Roman From ashipile at redhat.com Fri Mar 17 10:24:14 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 17 Mar 2017 10:24:14 +0000 Subject: hg: shenandoah/jdk9/hotspot: Matrix verification leaks reserved memory. Message-ID: <201703171024.v2HAOE0f017946@aojmv0008.oracle.com> Changeset: bb82fc129299 Author: shade Date: 2017-03-17 11:23 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/bb82fc129299 Matrix verification leaks reserved memory. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp From rkennke at redhat.com Fri Mar 17 17:06:36 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 17 Mar 2017 18:06:36 +0100 Subject: RFR: Fast matrix math & inlining Message-ID: <17eebcb4-2336-3f88-f3fb-e7c9ea03d057@redhat.com> This implements the same fast matrix math that Aleksey did in C2, but for the runtime C++ version. Shenandoah::set_connected() is called from the hot path in partial GC, so this should be benefitial. It also changes the signature of set_connected() to accept pointers instead of region indices, which simplifies calling code too. For debug builds, there is a little verification which checks that the matrix address calculated by that fast version and the old slow version match. SPECjvm compiler.compiler shows a slight improvement: baseline: 108,901 ?(99.9%) 42,594 ops/min [Average] Partial GC = 88,05 s (a = 144819 us) (n = 608) (lvls, us = 5977, 97656, 128906, 175781, 347946) patched: 119,307 ?(99.9%) 44,978 ops/min [Average] Partial GC = 81,14 s (a = 131076 us) (n = 619) (lvls, us = 4648, 93164, 119141, 160156, 283260) Tested with specjvm and gc-bench (arrayfragger) http://cr.openjdk.java.net/~rkennke/matrixmath/webrev.00/ Roman From shade at redhat.com Fri Mar 17 17:13:33 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 17 Mar 2017 18:13:33 +0100 Subject: RFR: Fast matrix math & inlining In-Reply-To: <17eebcb4-2336-3f88-f3fb-e7c9ea03d057@redhat.com> References: <17eebcb4-2336-3f88-f3fb-e7c9ea03d057@redhat.com> Message-ID: <9f62d599-b43b-75c3-1c50-58f9821a9ed4@redhat.com> On 03/17/2017 06:06 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/matrixmath/webrev.00/ Very nice. *) We need to either move the comment from GraphKit to ShenandoahConnectionMatrix about the math, or reference it otherwise. I would prefer it moved to SCMatrix, and then GraphKit to mention "look at SCMatrix for rationale". *) shenandoahHeap.inline.hpp: redundant to_idx 245 uint to_idx = _heap->heap_region_index_containing(obj); 246 _matrix->set_connected(o, obj); *) shenandoahHeap.inline.hpp: redundant from_idx 355 uint from_idx = heap_region_index_containing(copy_val); 356 UpdateMatrixClosure cl; Thanks, -Aleksey From zgu at redhat.com Fri Mar 17 17:14:46 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 17 Mar 2017 13:14:46 -0400 Subject: RFR(XS) [aarch64] Fixed syntax error Message-ID: <93eb98b9-e478-7a5f-deed-7e1053054952@redhat.com> Fixed a syntax error. http://cr.openjdk.java.net/~zgu/shenandoah/aarch64-comp-error/webrev.00/ Thanks, -Zhengyu From shade at redhat.com Fri Mar 17 17:17:55 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 17 Mar 2017 18:17:55 +0100 Subject: RFR(XS) [aarch64] Fixed syntax error In-Reply-To: <93eb98b9-e478-7a5f-deed-7e1053054952@redhat.com> References: <93eb98b9-e478-7a5f-deed-7e1053054952@redhat.com> Message-ID: <4cdcf2c6-c566-a336-04e6-036b9e55115e@redhat.com> On 03/17/2017 06:14 PM, Zhengyu Gu wrote: > Fixed a syntax error. > > http://cr.openjdk.java.net/~zgu/shenandoah/aarch64-comp-error/webrev.00/ D'oh. Looks okay. How did that compile before? -Aleksey From zgu at redhat.com Fri Mar 17 17:19:53 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 17 Mar 2017 13:19:53 -0400 Subject: RFR(XS) [aarch64] Fixed syntax error In-Reply-To: <4cdcf2c6-c566-a336-04e6-036b9e55115e@redhat.com> References: <93eb98b9-e478-7a5f-deed-7e1053054952@redhat.com> <4cdcf2c6-c566-a336-04e6-036b9e55115e@redhat.com> Message-ID: It did not! -Zhengyu On 03/17/2017 01:17 PM, Aleksey Shipilev wrote: > On 03/17/2017 06:14 PM, Zhengyu Gu wrote: >> Fixed a syntax error. >> >> http://cr.openjdk.java.net/~zgu/shenandoah/aarch64-comp-error/webrev.00/ > > D'oh. Looks okay. How did that compile before? > > -Aleksey > From zgu at redhat.com Fri Mar 17 17:29:53 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 17 Mar 2017 17:29:53 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fixed a syntax error. Message-ID: <201703171729.v2HHTrK2021731@aojmv0008.oracle.com> Changeset: dbbfff79b66a Author: zgu Date: 2017-03-17 13:26 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/dbbfff79b66a Fixed a syntax error. ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp From roman at kennke.org Fri Mar 17 19:59:27 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 17 Mar 2017 19:59:27 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fast matrix math & inlining. Message-ID: <201703171959.v2HJxRGW005983@aojmv0008.oracle.com> Changeset: 366aad72d1ee Author: rkennke Date: 2017-03-17 20:57 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/366aad72d1ee Fast matrix math & inlining. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp + src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.hpp ! src/share/vm/opto/graphKit.cpp From rkennke at redhat.com Fri Mar 17 21:02:05 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 17 Mar 2017 22:02:05 +0100 Subject: RFR: Fix full-gc matrix updates Message-ID: <916f946c-6153-21b9-b963-0f1855ecd070@redhat.com> When running the adjust-pointers pass in full-gc, we're also updating the matrix. We're using the current oop* for from-region, and the new location of the object for to-region. However, the from-object is also going to move! We need to take this into account. It's fixed by computing the offset of the from-object and its new location, and subtracting this from the from-pointer in the closure. I also snuck in two minor improvements: - Remove some old redundant code (from last patch) - use encode_store_heap_oop_not_null() instead of encode_store_heap_oop(). http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.00/ Ok? Roman From rkennke at redhat.com Fri Mar 17 21:10:28 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 17 Mar 2017 22:10:28 +0100 Subject: RFR: Fix full-gc matrix updates In-Reply-To: <916f946c-6153-21b9-b963-0f1855ecd070@redhat.com> References: <916f946c-6153-21b9-b963-0f1855ecd070@redhat.com> Message-ID: <5b27ad03-1452-5ba8-ce3a-a45fe521211f@redhat.com> Am 17.03.2017 um 22:02 schrieb Roman Kennke: > When running the adjust-pointers pass in full-gc, we're also updating > the matrix. We're using the current oop* for from-region, and the new > location of the object for to-region. However, the from-object is also > going to move! We need to take this into account. > > It's fixed by computing the offset of the from-object and its new > location, and subtracting this from the from-pointer in the closure. > > I also snuck in two minor improvements: > - Remove some old redundant code (from last patch) > - use encode_store_heap_oop_not_null() instead of encode_store_heap_oop(). > > http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.00/ > > > Ok? > > Roman > > Two little changes: - Use size_t instead of int, in case we need to address large memory. - Don't cast HeapWord* to oop, just to cast it back to HeapWord*. ;-) http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.01/ Roman From rkennke at redhat.com Fri Mar 17 21:16:01 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 17 Mar 2017 22:16:01 +0100 Subject: RFR: Fix full-gc matrix updates In-Reply-To: <5b27ad03-1452-5ba8-ce3a-a45fe521211f@redhat.com> References: <916f946c-6153-21b9-b963-0f1855ecd070@redhat.com> <5b27ad03-1452-5ba8-ce3a-a45fe521211f@redhat.com> Message-ID: Am 17.03.2017 um 22:10 schrieb Roman Kennke: > Am 17.03.2017 um 22:02 schrieb Roman Kennke: >> When running the adjust-pointers pass in full-gc, we're also updating >> the matrix. We're using the current oop* for from-region, and the new >> location of the object for to-region. However, the from-object is also >> going to move! We need to take this into account. >> >> It's fixed by computing the offset of the from-object and its new >> location, and subtracting this from the from-pointer in the closure. >> >> I also snuck in two minor improvements: >> - Remove some old redundant code (from last patch) >> - use encode_store_heap_oop_not_null() instead of encode_store_heap_oop(). >> >> http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.00/ >> >> >> Ok? >> >> Roman >> >> > Two little changes: > - Use size_t instead of int, in case we need to address large memory. > - Don't cast HeapWord* to oop, just to cast it back to HeapWord*. ;-) > > http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.01/ > Ok, another last change (sorry, it's almost weekend), as chf suggested on IRC, let's use pointer_delta() instead of pointer subtraction. http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.02/ Roman From shade at redhat.com Fri Mar 17 21:38:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 17 Mar 2017 22:38:50 +0100 Subject: RFR: Fix full-gc matrix updates In-Reply-To: References: <916f946c-6153-21b9-b963-0f1855ecd070@redhat.com> <5b27ad03-1452-5ba8-ce3a-a45fe521211f@redhat.com> Message-ID: <1283ca28-a702-4216-97f6-81f99dae071a@redhat.com> On 03/17/2017 10:16 PM, Roman Kennke wrote: > Am 17.03.2017 um 22:10 schrieb Roman Kennke: >> Am 17.03.2017 um 22:02 schrieb Roman Kennke: >>> When running the adjust-pointers pass in full-gc, we're also updating >>> the matrix. We're using the current oop* for from-region, and the new >>> location of the object for to-region. However, the from-object is also >>> going to move! We need to take this into account. >>> >>> It's fixed by computing the offset of the from-object and its new >>> location, and subtracting this from the from-pointer in the closure. >>> >>> I also snuck in two minor improvements: >>> - Remove some old redundant code (from last patch) >>> - use encode_store_heap_oop_not_null() instead of encode_store_heap_oop(). >>> >>> http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.00/ >>> >>> >>> Ok? >>> >>> Roman >>> >>> >> Two little changes: >> - Use size_t instead of int, in case we need to address large memory. >> - Don't cast HeapWord* to oop, just to cast it back to HeapWord*. ;-) >> >> http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.01/ >> > Ok, another last change (sorry, it's almost weekend), as chf suggested > on IRC, let's use pointer_delta() instead of pointer subtraction. > > http://cr.openjdk.java.net/~rkennke/partial-fixfullgc/webrev.02/ Put a comment there why this is safe, and we are good to go. Thanks, -Aleksey From roman at kennke.org Fri Mar 17 21:43:30 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 17 Mar 2017 21:43:30 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix full-gc matrix updates. Message-ID: <201703172143.v2HLhVJa029098@aojmv0008.oracle.com> Changeset: 5a46b01458c8 Author: rkennke Date: 2017-03-17 22:42 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/5a46b01458c8 Fix full-gc matrix updates. ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp From shade at redhat.com Mon Mar 20 09:02:59 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 10:02:59 +0100 Subject: RFR (S): Add the option to disable Shenandoah SATB barriers Message-ID: <34ef32fe-f7ac-7b24-b446-601f0892f22d@redhat.com> We thought it is folded under ShenandoahWriteBarrier, and some of it is. However, some paths enable SATB unconditionally, which distorts our differential performance runs. Introducing ShenandoahSATBBarriers option: http://cr.openjdk.java.net/~shade/shenandoah/satb-barriers-disable/webrev.02/ Testing: hotspot_gc_shenandoah, benchmarks Thanks, -Aleksey From aph at redhat.com Mon Mar 20 09:11:32 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Mar 2017 09:11:32 +0000 Subject: RFR (S): Add the option to disable Shenandoah SATB barriers In-Reply-To: <34ef32fe-f7ac-7b24-b446-601f0892f22d@redhat.com> References: <34ef32fe-f7ac-7b24-b446-601f0892f22d@redhat.com> Message-ID: On 20/03/17 09:02, Aleksey Shipilev wrote: > Introducing ShenandoahSATBBarriers option: > http://cr.openjdk.java.net/~shade/shenandoah/satb-barriers-disable/webrev.02/ Some of these changes are very intrusive in shared code. I suppose that when we get a proper abstract GC interface they will all be abstracted away, so perhaps it doesn't matter. Andrew. From shade at redhat.com Mon Mar 20 09:15:49 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 10:15:49 +0100 Subject: RFR (S): Add the option to disable Shenandoah SATB barriers In-Reply-To: References: <34ef32fe-f7ac-7b24-b446-601f0892f22d@redhat.com> Message-ID: <510da186-e2a1-1c0c-087f-1ce06d68f9d2@redhat.com> On 03/20/2017 10:11 AM, Andrew Haley wrote: > On 20/03/17 09:02, Aleksey Shipilev wrote: >> Introducing ShenandoahSATBBarriers option: >> http://cr.openjdk.java.net/~shade/shenandoah/satb-barriers-disable/webrev.02/ > > Some of these changes are very intrusive in shared code. I suppose > that when we get a proper abstract GC interface they will all be > abstracted away, so perhaps it doesn't matter. Yup. And also it will get easier once we depart from piggy-backing on G1 barrier code for e.g. pre-barriers. Thanks, -Aleksey From roman at kennke.org Mon Mar 20 09:41:07 2017 From: roman at kennke.org (Roman Kennke) Date: Mon, 20 Mar 2017 10:41:07 +0100 Subject: RFR (S): Add the option to disable Shenandoah SATB barriers In-Reply-To: <34ef32fe-f7ac-7b24-b446-601f0892f22d@redhat.com> References: <34ef32fe-f7ac-7b24-b446-601f0892f22d@redhat.com> Message-ID: <08DFCE0F-4AEE-43BE-AE93-E10EC5F647E7@kennke.org> Looks good to me! Am 20. M?rz 2017 10:02:59 MEZ schrieb Aleksey Shipilev : >We thought it is folded under ShenandoahWriteBarrier, and some of it >is. >However, some paths enable SATB unconditionally, which distorts our >differential >performance runs. > >Introducing ShenandoahSATBBarriers option: >http://cr.openjdk.java.net/~shade/shenandoah/satb-barriers-disable/webrev.02/ > >Testing: hotspot_gc_shenandoah, benchmarks > >Thanks, >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Mon Mar 20 09:47:12 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 09:47:12 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add the option to disable Shenandoah SATB barriers. Message-ID: <201703200947.v2K9lCfW013335@aojmv0008.oracle.com> Changeset: d945fcab1e9e Author: shade Date: 2017-03-20 10:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d945fcab1e9e Add the option to disable Shenandoah SATB barriers. ! src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp From shade at redhat.com Mon Mar 20 13:26:57 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 14:26:57 +0100 Subject: RFR (XS): Set matrix update probability to low in conditional Message-ID: <8ac1f836-913c-3f3e-7412-407c86a0155c@redhat.com> Hi, We can make the generated code a bit better by putting "unlikely" branch profile hint on the conditional matrix update: http://cr.openjdk.java.net/~shade/shenandoah/matrix-c2-prob/webrev.01/ Seems to help workloads that are sensitive to matrix barriers: Benchmark Mode Cnt Score Error Units # Baseline, -UseMatrix Compiler.compiler thrpt 50 93.041 ? 1.177 ops/min Compiler.sunflow thrpt 50 225.488 ? 3.148 ops/min XmlValidation.test thrpt 50 284.879 ? 1.190 ops/min # Baseline, +UseMatrix Compiler.compiler thrpt 50 79.702 ? 0.805 ops/min Compiler.sunflow thrpt 50 197.360 ? 2.629 ops/min XmlValidation.test thrpt 50 254.786 ? 0.881 ops/min # Patched, +UseMatrix Compiler.compiler thrpt 50 82.011 ? 0.865 ops/min Compiler.sunflow thrpt 50 202.404 ? 3.808 ops/min XmlValidation.test thrpt 50 257.733 ? 0.912 ops/min Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Mon Mar 20 13:40:24 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 14:40:24 +0100 Subject: RFR (XS): Set matrix update probability to low in conditional In-Reply-To: <8ac1f836-913c-3f3e-7412-407c86a0155c@redhat.com> References: <8ac1f836-913c-3f3e-7412-407c86a0155c@redhat.com> Message-ID: <66671ee3-e188-5df9-0cbf-0a1abdd1f672@redhat.com> Am 20.03.2017 um 14:26 schrieb Aleksey Shipilev: > Hi, > > We can make the generated code a bit better by putting "unlikely" branch profile > hint on the conditional matrix update: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-c2-prob/webrev.01/ > > Seems to help workloads that are sensitive to matrix barriers: > > Benchmark Mode Cnt Score Error Units > > # Baseline, -UseMatrix > Compiler.compiler thrpt 50 93.041 ? 1.177 ops/min > Compiler.sunflow thrpt 50 225.488 ? 3.148 ops/min > XmlValidation.test thrpt 50 284.879 ? 1.190 ops/min > > # Baseline, +UseMatrix > Compiler.compiler thrpt 50 79.702 ? 0.805 ops/min > Compiler.sunflow thrpt 50 197.360 ? 2.629 ops/min > XmlValidation.test thrpt 50 254.786 ? 0.881 ops/min > > # Patched, +UseMatrix > Compiler.compiler thrpt 50 82.011 ? 0.865 ops/min > Compiler.sunflow thrpt 50 202.404 ? 3.808 ops/min > XmlValidation.test thrpt 50 257.733 ? 0.912 ops/min > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Yes! Roman From ashipile at redhat.com Mon Mar 20 14:28:36 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 14:28:36 +0000 Subject: hg: shenandoah/jdk9/hotspot: Set matrix update probability to low in conditional. Message-ID: <201703201428.v2KESaDL029132@aojmv0008.oracle.com> Changeset: e6fb2d61b4b7 Author: shade Date: 2017-03-20 15:27 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e6fb2d61b4b7 Set matrix update probability to low in conditional. ! src/share/vm/opto/graphKit.cpp From shade at redhat.com Mon Mar 20 15:40:00 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 16:40:00 +0100 Subject: RFR (XS): -ShenandoahSATBBarrier disables matrix updates Message-ID: Hi, While studying the generated code, I realized that -ShenandoahSATBBuffer disables matrix updates too. Oops. This does not affect our performance runs just yet, because we enable SATB barriers before enabling matrix barriers. We should fix this oddity nevertheless: http://cr.openjdk.java.net/~shade/shenandoah/satb-barriers-disable-2/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing assembly Thanks, -Aleksey From rkennke at redhat.com Mon Mar 20 15:50:19 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 16:50:19 +0100 Subject: RFR (XS): -ShenandoahSATBBarrier disables matrix updates In-Reply-To: References: Message-ID: <420eafab-9c65-4f3d-d444-35e0587f85b3@redhat.com> Am 20.03.2017 um 16:40 schrieb Aleksey Shipilev: > Hi, > > While studying the generated code, I realized that -ShenandoahSATBBuffer > disables matrix updates too. Oops. This does not affect our performance runs > just yet, because we enable SATB barriers before enabling matrix barriers. We > should fix this oddity nevertheless: > http://cr.openjdk.java.net/~shade/shenandoah/satb-barriers-disable-2/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing assembly > > Thanks, > -Aleksey > ok From ashipile at redhat.com Mon Mar 20 15:51:40 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 15:51:40 +0000 Subject: hg: shenandoah/jdk9/hotspot: -ShenandoahSATBBarrier disables matrix updates. Message-ID: <201703201551.v2KFperk019561@aojmv0008.oracle.com> Changeset: 9f6b805e101f Author: shade Date: 2017-03-20 16:50 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/9f6b805e101f -ShenandoahSATBBarrier disables matrix updates. ! src/share/vm/opto/graphKit.cpp From rkennke at redhat.com Mon Mar 20 16:27:51 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 17:27:51 +0100 Subject: RFR: Empty task queues when cancelled partial GC Message-ID: When partial GC gets cancelled, we need to empty the task queues. I also added a small check to verify this, even for release build (shuold we make this debug-only?) http://cr.openjdk.java.net/~rkennke/fixemptyq/webrev.00/ Ok? From shade at redhat.com Mon Mar 20 16:31:57 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 17:31:57 +0100 Subject: RFR: Empty task queues when cancelled partial GC In-Reply-To: References: Message-ID: On 03/20/2017 05:27 PM, Roman Kennke wrote: > When partial GC gets cancelled, we need to empty the task queues. Right! We also need to visit the terminator on that path... > I also added a small check to verify this, even for release build > (shuold we make this debug-only?) Yes, wrap it up in ASSERT, and s/guarantee/assert/g -Aleksey From zgu at redhat.com Mon Mar 20 16:44:37 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Mar 2017 12:44:37 -0400 Subject: RFR: Empty task queues when cancelled partial GC In-Reply-To: References: Message-ID: Or can empty the queue at the beginning of each cycle. -Zhengyu On 03/20/2017 12:27 PM, Roman Kennke wrote: > When partial GC gets cancelled, we need to empty the task queues. > > I also added a small check to verify this, even for release build > (shuold we make this debug-only?) > > http://cr.openjdk.java.net/~rkennke/fixemptyq/webrev.00/ > > > Ok? > > > From shade at redhat.com Mon Mar 20 16:51:26 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 17:51:26 +0100 Subject: RFR: 9+8u: Fix build error in MacroAssembler::needs_explicit_null_check Message-ID: i586 build fails with: jdk8u/hotspot/src/share/vm/asm/assembler.cpp:323: error: integer constant is too large for ?unsigned long? type jdk8u/hotspot/src/share/vm/asm/assembler.cpp: In static member function ?static bool MacroAssembler::needs_explicit_null_check(intptr_t)?: jdk8u/hotspot/src/share/vm/asm/assembler.cpp:323: error: large integer implicitly truncated to unsigned type Fix: http://cr.openjdk.java.net/~shade/shenandoah/build/masm-null-check/webrev.01/ This affects both 9 and 8u. Testing: hotspot_gc_shenandoah/fastdebug with 9 and 8u Thanks, -Aleksey From rkennke at redhat.com Mon Mar 20 16:54:03 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 17:54:03 +0100 Subject: RFR: 9+8u: Fix build error in MacroAssembler::needs_explicit_null_check In-Reply-To: References: Message-ID: Am 20.03.2017 um 17:51 schrieb Aleksey Shipilev: > i586 build fails with: > > jdk8u/hotspot/src/share/vm/asm/assembler.cpp:323: error: integer constant is too > large for ?unsigned long? type > jdk8u/hotspot/src/share/vm/asm/assembler.cpp: In static member function ?static > bool MacroAssembler::needs_explicit_null_check(intptr_t)?: > jdk8u/hotspot/src/share/vm/asm/assembler.cpp:323: error: large integer > implicitly truncated to unsigned type > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/build/masm-null-check/webrev.01/ > > This affects both 9 and 8u. > > Testing: hotspot_gc_shenandoah/fastdebug with 9 and 8u > > Thanks, > -Aleksey > Looks good! From ashipile at redhat.com Mon Mar 20 16:56:12 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 16:56:12 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix build error in MacroAssembler::needs_explicit_null_check. Message-ID: <201703201656.v2KGuDxP005406@aojmv0008.oracle.com> Changeset: 3bb6f1ce716d Author: shade Date: 2017-03-20 17:55 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/3bb6f1ce716d Fix build error in MacroAssembler::needs_explicit_null_check. ! src/share/vm/asm/assembler.cpp From ashipile at redhat.com Mon Mar 20 16:56:16 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 16:56:16 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix build error in MacroAssembler::needs_explicit_null_check. Message-ID: <201703201656.v2KGuGNa005414@aojmv0008.oracle.com> Changeset: 851d9d3d635f Author: shade Date: 2017-03-20 17:55 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/851d9d3d635f Fix build error in MacroAssembler::needs_explicit_null_check. ! src/share/vm/asm/assembler.cpp From rkennke at redhat.com Mon Mar 20 17:15:51 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 18:15:51 +0100 Subject: RFR: Empty task queues when cancelled partial GC In-Reply-To: References: Message-ID: <8eb4c112-ce22-b2d0-eee8-3859c171a491@redhat.com> Am 20.03.2017 um 17:31 schrieb Aleksey Shipilev: > On 03/20/2017 05:27 PM, Roman Kennke wrote: >> When partial GC gets cancelled, we need to empty the task queues. > Right! We also need to visit the terminator on that path... I leave that to another patch. ;-) >> I also added a small check to verify this, even for release build >> (shuold we make this debug-only?) > Yes, wrap it up in ASSERT, and s/guarantee/assert/g I found out that set_empty() is not enough. We also need to clear the buffer and the overflow queue. However, TQS->clear() does that for us. I changed the patch to call clear() after all workers are done, and also put an assert before and after partial GC. http://cr.openjdk.java.net/~rkennke/fixemptyq/webrev.01/ ok now? Roman From shade at redhat.com Mon Mar 20 17:19:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 18:19:06 +0100 Subject: RFR: Empty task queues when cancelled partial GC In-Reply-To: <8eb4c112-ce22-b2d0-eee8-3859c171a491@redhat.com> References: <8eb4c112-ce22-b2d0-eee8-3859c171a491@redhat.com> Message-ID: <71037376-4079-fa46-9f1b-9da670a83734@redhat.com> On 03/20/2017 06:15 PM, Roman Kennke wrote: > Am 20.03.2017 um 17:31 schrieb Aleksey Shipilev: >> On 03/20/2017 05:27 PM, Roman Kennke wrote: >>> When partial GC gets cancelled, we need to empty the task queues. >> Right! We also need to visit the terminator on that path... > I leave that to another patch. ;-) >>> I also added a small check to verify this, even for release build >>> (shuold we make this debug-only?) >> Yes, wrap it up in ASSERT, and s/guarantee/assert/g > > I found out that set_empty() is not enough. We also need to clear the > buffer and the overflow queue. However, TQS->clear() does that for us. I > changed the patch to call clear() after all workers are done, and also > put an assert before and after partial GC. > > http://cr.openjdk.java.net/~rkennke/fixemptyq/webrev.01/ OK. -Aleksey From zgu at redhat.com Mon Mar 20 17:19:51 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Mar 2017 13:19:51 -0400 Subject: RFR: Empty task queues when cancelled partial GC In-Reply-To: <8eb4c112-ce22-b2d0-eee8-3859c171a491@redhat.com> References: <8eb4c112-ce22-b2d0-eee8-3859c171a491@redhat.com> Message-ID: Good to me. -Zhengyu On 03/20/2017 01:15 PM, Roman Kennke wrote: > Am 20.03.2017 um 17:31 schrieb Aleksey Shipilev: >> On 03/20/2017 05:27 PM, Roman Kennke wrote: >>> When partial GC gets cancelled, we need to empty the task queues. >> Right! We also need to visit the terminator on that path... > I leave that to another patch. ;-) >>> I also added a small check to verify this, even for release build >>> (shuold we make this debug-only?) >> Yes, wrap it up in ASSERT, and s/guarantee/assert/g > > I found out that set_empty() is not enough. We also need to clear the > buffer and the overflow queue. However, TQS->clear() does that for us. I > changed the patch to call clear() after all workers are done, and also > put an assert before and after partial GC. > > http://cr.openjdk.java.net/~rkennke/fixemptyq/webrev.01/ > > > ok now? > Roman > > From roman at kennke.org Mon Mar 20 17:23:51 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 20 Mar 2017 17:23:51 +0000 Subject: hg: shenandoah/jdk9/hotspot: Empty task queues when cancelled partial GC. Message-ID: <201703201723.v2KHNpIA012662@aojmv0008.oracle.com> Changeset: 821c63f347b7 Author: rkennke Date: 2017-03-20 18:08 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/821c63f347b7 Empty task queues when cancelled partial GC. ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From rkennke at redhat.com Mon Mar 20 17:26:03 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 18:26:03 +0100 Subject: RFR: Offer termination before leaving on cancelled GC Message-ID: <349a2911-0b4b-e260-f375-b2a267ba0fed@redhat.com> All exit paths from the work-loop in partial GC must offer termination on cancelled GC, otherwise a thread might get st?ck waiting for early-leavers. http://cr.openjdk.java.net/~rkennke/checkhandlecancelledgc/webrev.00/ Roman From shade at redhat.com Mon Mar 20 17:28:32 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 18:28:32 +0100 Subject: RFR: Use imulptr/addptr in MacroAssembler matrix update Message-ID: This fixes build failure on i586, even though we never visit this code in i586 binary: http://cr.openjdk.java.net/~shade/shenandoah/build/masm-matrix-ptr/webrev.01/ In x86_64, imulptr/addptr alias to the same imulq/addq we have now. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From shade at redhat.com Mon Mar 20 17:29:20 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 18:29:20 +0100 Subject: RFR: Offer termination before leaving on cancelled GC In-Reply-To: <349a2911-0b4b-e260-f375-b2a267ba0fed@redhat.com> References: <349a2911-0b4b-e260-f375-b2a267ba0fed@redhat.com> Message-ID: On 03/20/2017 06:26 PM, Roman Kennke wrote: > All exit paths from the work-loop in partial GC must offer termination > on cancelled GC, otherwise a thread might get st?ck waiting for > early-leavers. > > http://cr.openjdk.java.net/~rkennke/checkhandlecancelledgc/webrev.00/ Looks good to me. -Aleksey From roman at kennke.org Mon Mar 20 17:33:53 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 20 Mar 2017 17:33:53 +0000 Subject: hg: shenandoah/jdk9/hotspot: Offer termination before leaving on cancelled GC. Message-ID: <201703201733.v2KHXrrQ015617@aojmv0008.oracle.com> Changeset: e2520db37502 Author: rkennke Date: 2017-03-20 18:23 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e2520db37502 Offer termination before leaving on cancelled GC. ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From rkennke at redhat.com Mon Mar 20 17:33:23 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 18:33:23 +0100 Subject: RFR: Use imulptr/addptr in MacroAssembler matrix update In-Reply-To: References: Message-ID: <7d1bbb72-5f00-c527-bf9a-1eddb0e6acdf@redhat.com> Am 20.03.2017 um 18:28 schrieb Aleksey Shipilev: > This fixes build failure on i586, even though we never visit this code in i586 > binary: > http://cr.openjdk.java.net/~shade/shenandoah/build/masm-matrix-ptr/webrev.01/ > > In x86_64, imulptr/addptr alias to the same imulq/addq we have now. > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Yes From ashipile at redhat.com Mon Mar 20 17:35:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 17:35:11 +0000 Subject: hg: shenandoah/jdk9/hotspot: Use imulptr/addptr in MacroAssembler matrix update. Message-ID: <201703201735.v2KHZBqA016241@aojmv0008.oracle.com> Changeset: 414bd3d76436 Author: shade Date: 2017-03-20 18:33 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/414bd3d76436 Use imulptr/addptr in MacroAssembler matrix update. ! src/cpu/x86/vm/macroAssembler_x86.cpp From shade at redhat.com Mon Mar 20 17:59:17 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 18:59:17 +0100 Subject: RFR: 9+8u: MacroAssembler and ShenandoahBarrierSet reference x86_64 registers Message-ID: Hi, Another batch of i586 build failure fixes. Conditionalize shared Shenandoah code with _LP64 where they reference x86_64 registers. This allows us to build: http://cr.openjdk.java.net/~shade/shenandoah/build/noregs-i586/webrev.01/ This affects both 9 and 8u. Testing: hotspot_gc_shenandoah for both 9 and 8u. -Aleksey From rkennke at redhat.com Mon Mar 20 18:07:56 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 19:07:56 +0100 Subject: RFR: 9+8u: MacroAssembler and ShenandoahBarrierSet reference x86_64 registers In-Reply-To: References: Message-ID: Am 20.03.2017 um 18:59 schrieb Aleksey Shipilev: > Hi, > > Another batch of i586 build failure fixes. Conditionalize shared Shenandoah code > with _LP64 where they reference x86_64 registers. This allows us to build: > http://cr.openjdk.java.net/~shade/shenandoah/build/noregs-i586/webrev.01/ > > This affects both 9 and 8u. > > Testing: hotspot_gc_shenandoah for both 9 and 8u. > > -Aleksey > > Yes. Thanks for finding+fixing it! Roman From ashipile at redhat.com Mon Mar 20 18:09:27 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 18:09:27 +0000 Subject: hg: shenandoah/jdk8u/hotspot: MacroAssembler and ShenandoahBarrierSet reference x86_64 registers. Message-ID: <201703201809.v2KI9ROD024996@aojmv0008.oracle.com> Changeset: 32b90af18832 Author: shade Date: 2017-03-20 19:08 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/32b90af18832 MacroAssembler and ShenandoahBarrierSet reference x86_64 registers. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp From ashipile at redhat.com Mon Mar 20 18:09:30 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 18:09:30 +0000 Subject: hg: shenandoah/jdk9/hotspot: MacroAssembler and ShenandoahBarrierSet reference x86_64 registers. Message-ID: <201703201809.v2KI9UGU024999@aojmv0008.oracle.com> Changeset: d65f1b7f3da2 Author: shade Date: 2017-03-20 19:08 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d65f1b7f3da2 MacroAssembler and ShenandoahBarrierSet reference x86_64 registers. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp From shade at redhat.com Mon Mar 20 18:25:54 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 19:25:54 +0100 Subject: RFR: 9+8u: Use size_t constants instead of unsigned longs for MAX2 Message-ID: <5fe97a4b-8d6b-2429-0032-62cf655b802f@redhat.com> Using MAX2(size_t, unsigned long) only works on x86_64. It fails to build on i586, and we should really use size_t in the second argument. Fix: http://cr.openjdk.java.net/~shade/shenandoah/build/max2-size_t/webrev.01/ (Of course, C++ does not have size_t literals) This affects both 9 and 8u. Testing: hotspot_gc_shenandoah on both 9 and 8u. Thanks, -Aleksey From rkennke at redhat.com Mon Mar 20 18:29:50 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 19:29:50 +0100 Subject: RFR: 9+8u: Use size_t constants instead of unsigned longs for MAX2 In-Reply-To: <5fe97a4b-8d6b-2429-0032-62cf655b802f@redhat.com> References: <5fe97a4b-8d6b-2429-0032-62cf655b802f@redhat.com> Message-ID: Yes Am 20. M?rz 2017 19:25:54 MEZ schrieb Aleksey Shipilev : >Using MAX2(size_t, unsigned long) only works on x86_64. It fails to >build on >i586, and we should really use size_t in the second argument. Fix: >http://cr.openjdk.java.net/~shade/shenandoah/build/max2-size_t/webrev.01/ > >(Of course, C++ does not have size_t literals) > >This affects both 9 and 8u. > >Testing: hotspot_gc_shenandoah on both 9 and 8u. > >Thanks, >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Mon Mar 20 18:31:28 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 18:31:28 +0000 Subject: hg: shenandoah/jdk9/hotspot: Use size_t constants instead of unsigned longs for MAX2. Message-ID: <201703201831.v2KIVSdk000745@aojmv0008.oracle.com> Changeset: 5ec3a55d7300 Author: shade Date: 2017-03-20 19:30 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/5ec3a55d7300 Use size_t constants instead of unsigned longs for MAX2. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From ashipile at redhat.com Mon Mar 20 18:31:42 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 18:31:42 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Use size_t constants instead of unsigned longs for MAX2. Message-ID: <201703201831.v2KIVgix001070@aojmv0008.oracle.com> Changeset: 333316c6c5a7 Author: shade Date: 2017-03-20 19:30 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/333316c6c5a7 Use size_t constants instead of unsigned longs for MAX2. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp From shade at redhat.com Mon Mar 20 19:23:36 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Mar 2017 20:23:36 +0100 Subject: RFR: 9+8u: Fix linkage error on i586, incrementq and addq are not implemented Message-ID: <617aa1de-a8fa-5743-0c13-16f831a8c3f8@redhat.com> This fixes the last-to-final failure on i586 for shenandoah-jdk9. incrementq and addq are not implemented in i586, so it fails during linkage: http://cr.openjdk.java.net/~shade/shenandoah/build/noq-i586/webrev.01 Testing: hotspot_gc_shenandoah for both 9 and 8u -Aleksey From rkennke at redhat.com Mon Mar 20 20:04:17 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Mar 2017 21:04:17 +0100 Subject: RFR: 9+8u: Fix linkage error on i586, incrementq and addq are not implemented In-Reply-To: <617aa1de-a8fa-5743-0c13-16f831a8c3f8@redhat.com> References: <617aa1de-a8fa-5743-0c13-16f831a8c3f8@redhat.com> Message-ID: <04E50215-8C53-463E-9AD0-91FDFFA90046@redhat.com> Yes, please! And thanks! Am 20. M?rz 2017 20:23:36 MEZ schrieb Aleksey Shipilev : >This fixes the last-to-final failure on i586 for shenandoah-jdk9. > >incrementq and addq are not implemented in i586, so it fails during >linkage: > http://cr.openjdk.java.net/~shade/shenandoah/build/noq-i586/webrev.01 > >Testing: hotspot_gc_shenandoah for both 9 and 8u > >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Mon Mar 20 20:05:45 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 20:05:45 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix linkage error on i586, incrementq and addq are not implemented. Message-ID: <201703202005.v2KK5jcp024271@aojmv0008.oracle.com> Changeset: 8f5745f844a1 Author: shade Date: 2017-03-20 21:05 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/8f5745f844a1 Fix linkage error on i586, incrementq and addq are not implemented. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/templateTable_x86.cpp From ashipile at redhat.com Mon Mar 20 20:07:32 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 20 Mar 2017 20:07:32 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix linkage error on i586, incrementq and addq are not implemented. Message-ID: <201703202007.v2KK7Wg2024619@aojmv0008.oracle.com> Changeset: 97f3b9319f44 Author: shade Date: 2017-03-20 21:06 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/97f3b9319f44 Fix linkage error on i586, incrementq and addq are not implemented. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp From shade at redhat.com Tue Mar 21 08:57:21 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 09:57:21 +0100 Subject: RFR: Loop strip mining options should be uintx Message-ID: <3ca60285-50cd-165c-3fe4-e45b14f11316@redhat.com> Otherwise VM invocation on i586 fails with: Creating support/interim-jmods/java.base.jmod intx LoopStripMiningIter=0 is outside the allowed range [ 0 ... -1 ] intx LoopStripMiningIterShortLoop=0 is outside the allowed range [ 0 ... -1 ] Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. That is because intx disagrees with max_juint bound. The fix is to turn both options to uintx: http://cr.openjdk.java.net/~shade/shenandoah/build/lsm-uintx/webrev.01/ Testing: hotspot_gc_shenandoah, i586 java -version -Aleksey From rkennke at redhat.com Tue Mar 21 10:01:39 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Mar 2017 11:01:39 +0100 Subject: RFR: Loop strip mining options should be uintx In-Reply-To: <3ca60285-50cd-165c-3fe4-e45b14f11316@redhat.com> References: <3ca60285-50cd-165c-3fe4-e45b14f11316@redhat.com> Message-ID: <37f5287a-9fb9-60fb-a9f2-7e1ca2cbc00d@redhat.com> Am 21.03.2017 um 09:57 schrieb Aleksey Shipilev: > Otherwise VM invocation on i586 fails with: > > Creating support/interim-jmods/java.base.jmod > intx LoopStripMiningIter=0 is outside the allowed range [ 0 ... -1 ] > intx LoopStripMiningIterShortLoop=0 is outside the allowed range [ 0 ... -1 ] > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > That is because intx disagrees with max_juint bound. The fix is to turn both > options to uintx: > http://cr.openjdk.java.net/~shade/shenandoah/build/lsm-uintx/webrev.01/ > > Testing: hotspot_gc_shenandoah, i586 java -version > > -Aleksey > Yes! From ashipile at redhat.com Tue Mar 21 10:03:18 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 10:03:18 +0000 Subject: hg: shenandoah/jdk9/hotspot: Loop strip mining options should be uintx. Message-ID: <201703211003.v2LA3I9T014051@aojmv0008.oracle.com> Changeset: f6d99465f832 Author: shade Date: 2017-03-21 11:02 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/f6d99465f832 Loop strip mining options should be uintx. ! src/share/vm/opto/c2_globals.hpp From rkennke at redhat.com Tue Mar 21 10:26:22 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Mar 2017 11:26:22 +0100 Subject: RFR: Revert part of StubGenerator to ease porting Message-ID: <43bd7da5-d502-371f-1bc0-21ba3d3ff1f6@redhat.com> This reverts our modifications to StubGenerator and related code and removes the 3rd stub generation phase that used to generate the Shenandoah stub. This makes it easier to port to platforms, because it would otherwise require changes in all arches. The downside is that we cannot use our write-barrier stub in the interpreter. I put back in a specialized write-barrier for the interpreter to handle this. I tested it on x86_64 and aarch64, Aleksey tested it on i586. Both jdk9 and jdk8u. http://cr.openjdk.java.net/~rkennke/fixstubgen/webrev.00/ Ok? Roman From shade at redhat.com Tue Mar 21 10:30:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 11:30:06 +0100 Subject: RFR: Revert part of StubGenerator to ease porting In-Reply-To: <43bd7da5-d502-371f-1bc0-21ba3d3ff1f6@redhat.com> References: <43bd7da5-d502-371f-1bc0-21ba3d3ff1f6@redhat.com> Message-ID: <2a1d3406-e931-ad8e-8712-d4bc8d60ca0f@redhat.com> On 03/21/2017 11:26 AM, Roman Kennke wrote: > This reverts our modifications to StubGenerator and related code and > removes the 3rd stub generation phase that used to generate the > Shenandoah stub. This makes it easier to port to platforms, because it > would otherwise require changes in all arches. > > The downside is that we cannot use our write-barrier stub in the > interpreter. I put back in a specialized write-barrier for the > interpreter to handle this. > > I tested it on x86_64 and aarch64, Aleksey tested it on i586. Both jdk9 > and jdk8u. > > http://cr.openjdk.java.net/~rkennke/fixstubgen/webrev.00/ Thank you, looks good. *) This can be pruned: 430 // tty->print_cr("called interpreter write barrier with: %p result: %p", src, result); -Aleksey From roman at kennke.org Tue Mar 21 10:32:47 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 21 Mar 2017 10:32:47 +0000 Subject: hg: shenandoah/jdk9/hotspot: Revert part of StubGenerator to ease porting. Message-ID: <201703211032.v2LAWlsk021975@aojmv0008.oracle.com> Changeset: a7f9abea2a6d Author: rkennke Date: 2017-03-21 11:32 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a7f9abea2a6d Revert part of StubGenerator to ease porting. ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/stubRoutines_aarch64.hpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86.hpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From roman at kennke.org Tue Mar 21 10:32:59 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 21 Mar 2017 10:32:59 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Revert part of StubGenerator to ease porting. Message-ID: <201703211033.v2LAX09I022120@aojmv0008.oracle.com> Changeset: ddb686192185 Author: rkennke Date: 2017-03-21 11:31 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/ddb686192185 Revert part of StubGenerator to ease porting. ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/stubRoutines_aarch64.hpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From shade at redhat.com Tue Mar 21 11:01:28 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 12:01:28 +0100 Subject: RFR: Exit gracefully when Shenandoah is not supported Message-ID: <32766530-709b-bd1d-b40b-2465c593385b@redhat.com> This affects only 9. It will crash like this: $ build/linux-x86-normal-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -version OpenJDK Server VM warning: -XX:+UseShenandoahGC not supported in this VM # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (universe.cpp:745), pid=18763, tid=18764 # Error: ShouldNotReachHere() The trouble is that JDK 9 code is missing UNSUPPORTED_GC_OPTION macro, which used to default to Serial GC in cases like this. Let's just exit gracefully: diff -r a7f9abea2a6d src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Tue Mar 21 11:32:00 2017 +0100 +++ b/src/share/vm/runtime/arguments.cpp Tue Mar 21 12:00:55 2017 +0100 @@ -2053,7 +2053,7 @@ void Arguments::set_shenandoah_gc_flags() { #if !(defined AARCH64 || defined AMD64) - UNSUPPORTED_OPTION(UseShenandoahGC); + vm_exit_during_initialization("Shenandoah GC is not supported on this platform."); #endif #ifdef _LP64 $ build/linux-x86-normal-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -version Error occurred during initialization of VM Shenandoah GC is not supported on this platform. Thanks, -Aleksey From rkennke at redhat.com Tue Mar 21 11:11:25 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Mar 2017 12:11:25 +0100 Subject: RFR: Exit gracefully when Shenandoah is not supported In-Reply-To: <32766530-709b-bd1d-b40b-2465c593385b@redhat.com> References: <32766530-709b-bd1d-b40b-2465c593385b@redhat.com> Message-ID: <80DA0002-F379-4318-BB49-2189224995FB@redhat.com> Yes, please Am 21. M?rz 2017 12:01:28 MEZ schrieb Aleksey Shipilev : >This affects only 9. It will crash like this: > >$ build/linux-x86-normal-server-release/images/jdk/bin/java >-XX:+UseShenandoahGC >-version >OpenJDK Server VM warning: -XX:+UseShenandoahGC not supported in this >VM ># ># A fatal error has been detected by the Java Runtime Environment: ># ># Internal Error (universe.cpp:745), pid=18763, tid=18764 ># Error: ShouldNotReachHere() > > >The trouble is that JDK 9 code is missing UNSUPPORTED_GC_OPTION macro, >which >used to default to Serial GC in cases like this. Let's just exit >gracefully: > >diff -r a7f9abea2a6d src/share/vm/runtime/arguments.cpp >--- a/src/share/vm/runtime/arguments.cpp Tue Mar 21 11:32:00 2017 +0100 >+++ b/src/share/vm/runtime/arguments.cpp Tue Mar 21 12:00:55 2017 +0100 >@@ -2053,7 +2053,7 @@ > void Arguments::set_shenandoah_gc_flags() { > > #if !(defined AARCH64 || defined AMD64) >- UNSUPPORTED_OPTION(UseShenandoahGC); >+ vm_exit_during_initialization("Shenandoah GC is not supported on >this >platform."); > #endif > > #ifdef _LP64 > >$ build/linux-x86-normal-server-release/images/jdk/bin/java >-XX:+UseShenandoahGC >-version >Error occurred during initialization of VM >Shenandoah GC is not supported on this platform. > > >Thanks, >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Tue Mar 21 11:13:30 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 11:13:30 +0000 Subject: hg: shenandoah/jdk9/hotspot: Exit gracefully when Shenandoah is not supported. Message-ID: <201703211113.v2LBDUb2001682@aojmv0008.oracle.com> Changeset: 047a2d61088f Author: shade Date: 2017-03-21 12:12 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/047a2d61088f Exit gracefully when Shenandoah is not supported. ! src/share/vm/runtime/arguments.cpp From shade at redhat.com Tue Mar 21 13:49:19 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 14:49:19 +0100 Subject: RFR: ObjChunkedArrayTask enum constants overflow Message-ID: Hi, This is caught by MSVC x86_64. We apparently cannot use large enum constants, because they would not fit into whatever MSVC is allocating for enum type. I would scope the enum to use uintptr_t, but this is only available since C++11. The apparent way out is to keep only small enum constants, and inline others to get the typing right: http://cr.openjdk.java.net/~shade/shenandoah/build/tq-enums/webrev.01/ While this affects 8u too, this patch is only for 9. This is because the amount of testing needed for Linux x86_64, i586, Windows x86_64. We will backport this to 8u once 9 builds fully on Windows x86_64. I eyeballed the compiled object code to see we still constant-fold these properly. Testing: builds on Linux x86_64, i586, Windows x86_64; Linux x86_64 hotspot_gc_shenandoah. Thanks, -Aleksey From rkennke at redhat.com Tue Mar 21 13:51:53 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Mar 2017 14:51:53 +0100 Subject: RFR: ObjChunkedArrayTask enum constants overflow In-Reply-To: References: Message-ID: <163C94D6-B908-4DAE-B85D-966AA1BE623E@redhat.com> Okidoki Am 21. M?rz 2017 14:49:19 MEZ schrieb Aleksey Shipilev : >Hi, > >This is caught by MSVC x86_64. We apparently cannot use large enum >constants, >because they would not fit into whatever MSVC is allocating for enum >type. I >would scope the enum to use uintptr_t, but this is only available since >C++11. >The apparent way out is to keep only small enum constants, and inline >others to >get the typing right: > http://cr.openjdk.java.net/~shade/shenandoah/build/tq-enums/webrev.01/ > >While this affects 8u too, this patch is only for 9. This is because >the amount >of testing needed for Linux x86_64, i586, Windows x86_64. We will >backport this >to 8u once 9 builds fully on Windows x86_64. > >I eyeballed the compiled object code to see we still constant-fold >these properly. > >Testing: builds on Linux x86_64, i586, Windows x86_64; Linux x86_64 >hotspot_gc_shenandoah. > >Thanks, >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Tue Mar 21 14:05:47 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 14:05:47 +0000 Subject: hg: shenandoah/jdk9/hotspot: ObjChunkedArrayTask enum constants overflow. Message-ID: <201703211405.v2LE5lUa028175@aojmv0008.oracle.com> Changeset: 0548633ee749 Author: shade Date: 2017-03-21 15:04 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/0548633ee749 ObjChunkedArrayTask enum constants overflow. ! src/share/vm/gc/shared/taskqueue.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/runtime/arguments.cpp From shade at redhat.com Tue Mar 21 15:07:48 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 16:07:48 +0100 Subject: RFR: 9+8u: ShenandoahHeap::_cancelled_gc should be consistently treated as jbyte Message-ID: <33be32c1-1226-5d69-e254-d2f48841bf8b@redhat.com> Hi, Compilers do complain when you use jbyte and bools interchangeably. Also we cast out constness in setters, what-what? MSVC fails Windows build. Fix: http://cr.openjdk.java.net/~shade/shenandoah/build/cancel-gc-jbyte/webrev.01/ This affects both 9 and 8u. Testing: hotspot_gc_shenandoah, 9 and 8u Thanks, -Aleksey From roman at kennke.org Tue Mar 21 15:09:40 2017 From: roman at kennke.org (Roman Kennke) Date: Tue, 21 Mar 2017 16:09:40 +0100 Subject: RFR: 9+8u: ShenandoahHeap::_cancelled_gc should be consistently treated as jbyte In-Reply-To: <33be32c1-1226-5d69-e254-d2f48841bf8b@redhat.com> References: <33be32c1-1226-5d69-e254-d2f48841bf8b@redhat.com> Message-ID: Am 21.03.2017 um 16:07 schrieb Aleksey Shipilev: > Hi, > > Compilers do complain when you use jbyte and bools interchangeably. Also we cast > out constness in setters, what-what? MSVC fails Windows build. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/build/cancel-gc-jbyte/webrev.01/ > > This affects both 9 and 8u. > > Testing: hotspot_gc_shenandoah, 9 and 8u > > Thanks, > -Aleksey > > Looks reasonable. Yes. From ashipile at redhat.com Tue Mar 21 16:24:58 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 16:24:58 +0000 Subject: hg: shenandoah/jdk9/hotspot: ShenandoahHeap::_cancelled_gc should be consistently treated as jbyte. Message-ID: <201703211624.v2LGOwmN011395@aojmv0008.oracle.com> Changeset: 82450573a934 Author: shade Date: 2017-03-21 17:24 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/82450573a934 ShenandoahHeap::_cancelled_gc should be consistently treated as jbyte. ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp From ashipile at redhat.com Tue Mar 21 16:28:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 16:28:03 +0000 Subject: hg: shenandoah/jdk8u/hotspot: ShenandoahHeap::_cancelled_gc should be consistently treated as jbyte. Message-ID: <201703211628.v2LGS33m012148@aojmv0008.oracle.com> Changeset: 5033ba844c51 Author: shade Date: 2017-03-21 17:27 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/5033ba844c51 ShenandoahHeap::_cancelled_gc should be consistently treated as jbyte. ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp From zgu at redhat.com Tue Mar 21 17:23:53 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 21 Mar 2017 13:23:53 -0400 Subject: RFR(XS): Fix bad constant definition Message-ID: <8aa5b5f1-a168-241f-97cd-ec19cd27784d@redhat.com> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/bad_const/webrev.00/ Thanks, -Zhengyu From shade at redhat.com Tue Mar 21 17:27:22 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 18:27:22 +0100 Subject: RFR(XS): Fix bad constant definition In-Reply-To: <8aa5b5f1-a168-241f-97cd-ec19cd27784d@redhat.com> References: <8aa5b5f1-a168-241f-97cd-ec19cd27784d@redhat.com> Message-ID: <2b72133b-93d5-ab56-c490-07eb0ca37c91@redhat.com> On 03/21/2017 06:23 PM, Zhengyu Gu wrote: > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/bad_const/webrev.00/ Looks good, thanks! Please also push to 8u. -Aleksey From zgu at redhat.com Tue Mar 21 17:30:02 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 21 Mar 2017 17:30:02 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix bad constant definition Message-ID: <201703211730.v2LHU2PX000193@aojmv0008.oracle.com> Changeset: 555f3a32bf60 Author: zgu Date: 2017-03-21 13:29 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/555f3a32bf60 Fix bad constant definition ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp From shade at redhat.com Tue Mar 21 17:51:49 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 18:51:49 +0100 Subject: RFR: 9+8u: Collection policy cleanups Message-ID: <6675950c-41f3-ad51-dfb3-6f1367ec6b77@redhat.com> Hi, This fixes a few compiler warnings that break MSVC build. First, we cannot stack-alloc RegionGarbage array -- we have fixed it in one place before, but not in the other one. Then, there are some int<->size_t conversions. Fix: http://cr.openjdk.java.net/~shade/shenandoah/collection-policy-cleanup/webrev.01/ This affects both 8u and 9. Testing: hotspot_gc_shenandoah with 9 and 8u. Thanks, -Aleksey From zgu at redhat.com Tue Mar 21 18:03:03 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 21 Mar 2017 18:03:03 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix bad constant definition Message-ID: <201703211803.v2LI33q3009744@aojmv0008.oracle.com> Changeset: 0b59034b0192 Author: zgu Date: 2017-03-21 13:53 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0b59034b0192 Fix bad constant definition ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp From zgu at redhat.com Tue Mar 21 18:05:14 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 21 Mar 2017 14:05:14 -0400 Subject: RFR: 9+8u: Collection policy cleanups In-Reply-To: <6675950c-41f3-ad51-dfb3-6f1367ec6b77@redhat.com> References: <6675950c-41f3-ad51-dfb3-6f1367ec6b77@redhat.com> Message-ID: Good to me. -Zhengyu On 03/21/2017 01:51 PM, Aleksey Shipilev wrote: > Hi, > > This fixes a few compiler warnings that break MSVC build. First, we cannot > stack-alloc RegionGarbage array -- we have fixed it in one place before, but not > in the other one. Then, there are some int<->size_t conversions. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/collection-policy-cleanup/webrev.01/ > > This affects both 8u and 9. > > Testing: hotspot_gc_shenandoah with 9 and 8u. > > Thanks, > -Aleksey > From ashipile at redhat.com Tue Mar 21 18:07:53 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 18:07:53 +0000 Subject: hg: shenandoah/jdk9/hotspot: Collection policy cleanups. Message-ID: <201703211807.v2LI7rkr010956@aojmv0008.oracle.com> Changeset: 6aae3f3ae593 Author: shade Date: 2017-03-21 19:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/6aae3f3ae593 Collection policy cleanups. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From ashipile at redhat.com Tue Mar 21 18:21:10 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 18:21:10 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Collection policy cleanups. Message-ID: <201703211821.v2LILBJ6015417@aojmv0008.oracle.com> Changeset: a096b11d21f7 Author: shade Date: 2017-03-21 19:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a096b11d21f7 Collection policy cleanups. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp From shade at redhat.com Tue Mar 21 19:43:29 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 20:43:29 +0100 Subject: RFR: 9+8u: Add missing precompiled.hpp to Shenandoah files Message-ID: <6bff9e4a-72db-032d-6ac0-bf5cf2cd964c@redhat.com> Hi, This prevents MSVC builds. Add missing precompiled.hpp: http://cr.openjdk.java.net/~shade/shenandoah/build/precompiled/webrev.01/ Similar thing goes to 8u. Testing: hotspot_gc_shenandoah for 8u and 9. -Aleksey From roman at kennke.org Tue Mar 21 19:45:53 2017 From: roman at kennke.org (Roman Kennke) Date: Tue, 21 Mar 2017 20:45:53 +0100 Subject: RFR: 9+8u: Add missing precompiled.hpp to Shenandoah files In-Reply-To: <6bff9e4a-72db-032d-6ac0-bf5cf2cd964c@redhat.com> References: <6bff9e4a-72db-032d-6ac0-bf5cf2cd964c@redhat.com> Message-ID: <4FF137CA-43DA-45BD-BAF3-3B07CE05E641@kennke.org> Eww. OK. Am 21. M?rz 2017 20:43:29 MEZ schrieb Aleksey Shipilev : >Hi, > >This prevents MSVC builds. Add missing precompiled.hpp: >http://cr.openjdk.java.net/~shade/shenandoah/build/precompiled/webrev.01/ > >Similar thing goes to 8u. > >Testing: hotspot_gc_shenandoah for 8u and 9. > >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Tue Mar 21 19:47:49 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 19:47:49 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add missing precompiled.hpp to Shenandoah files. Message-ID: <201703211947.v2LJlnYD009334@aojmv0008.oracle.com> Changeset: 4975ba41d39a Author: shade Date: 2017-03-21 20:47 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/4975ba41d39a Add missing precompiled.hpp to Shenandoah files. ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahPhaseTimes.cpp ! src/share/vm/gc/shenandoah/shenandoah_globals.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp From ashipile at redhat.com Tue Mar 21 19:48:01 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 19:48:01 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Add missing precompiled.hpp to Shenandoah files. Message-ID: <201703211948.v2LJm1hh009440@aojmv0008.oracle.com> Changeset: 087fd362f9f2 Author: shade Date: 2017-03-21 20:47 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/087fd362f9f2 Add missing precompiled.hpp to Shenandoah files. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimes.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp From shade at redhat.com Tue Mar 21 20:23:44 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 21:23:44 +0100 Subject: RFR: Use size_t consistently for region sizes, counts Message-ID: <8137f565-9d43-253c-74f2-159903fede3b@redhat.com> Hi, Compilers complain how we use uint and size_t interchangeably for region sizes, counts, and math involving them. This yields everything to size_t: http://cr.openjdk.java.net/~shade/shenandoah/region-idx-size_t/webrev.01/ Going to backport this to 8u later. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From zgu at redhat.com Tue Mar 21 20:32:31 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 21 Mar 2017 16:32:31 -0400 Subject: RFR: Use size_t consistently for region sizes, counts In-Reply-To: <8137f565-9d43-253c-74f2-159903fede3b@redhat.com> References: <8137f565-9d43-253c-74f2-159903fede3b@redhat.com> Message-ID: Good to me. -Zhengyu On 03/21/2017 04:23 PM, Aleksey Shipilev wrote: > Hi, > > Compilers complain how we use uint and size_t interchangeably for region sizes, > counts, and math involving them. This yields everything to size_t: > http://cr.openjdk.java.net/~shade/shenandoah/region-idx-size_t/webrev.01/ > > Going to backport this to 8u later. > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > From ashipile at redhat.com Tue Mar 21 20:35:01 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 20:35:01 +0000 Subject: hg: shenandoah/jdk9/hotspot: Use size_t consistently for region sizes, counts. Message-ID: <201703212035.v2LKZ14r021807@aojmv0008.oracle.com> Changeset: e17250b1955f Author: shade Date: 2017-03-21 21:34 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e17250b1955f Use size_t consistently for region sizes, counts. ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.hpp From shade at redhat.com Tue Mar 21 20:37:13 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 21:37:13 +0100 Subject: RFR: 9+8u: Remove stray include mman.h Message-ID: <166530ac-9a7e-8976-0795-e1002c3dda93@redhat.com> This is not available on Windows, obviously. And we don't need it in Shenandoah code, because os::protect_memory does the OS-specific stuff for us. $ hg diff diff -r e17250b1955f src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp --- a/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Tue Mar 21 21:34:20 2017 +0100 +++ b/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Tue Mar 21 21:35:08 2017 +0100 @@ -126,8 +126,6 @@ #endif } -#include - #ifdef ASSERT void ShenandoahHeapRegion::memProtectionOn() { Testing: hotspot_gc_shenandoah -Aleksey From rkennke at redhat.com Tue Mar 21 20:39:59 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Mar 2017 21:39:59 +0100 Subject: RFR: 9+8u: Remove stray include mman.h In-Reply-To: <166530ac-9a7e-8976-0795-e1002c3dda93@redhat.com> References: <166530ac-9a7e-8976-0795-e1002c3dda93@redhat.com> Message-ID: <02b56663-9be1-fe56-1824-4ee1e416c742@redhat.com> Am 21.03.2017 um 21:37 schrieb Aleksey Shipilev: > This is not available on Windows, obviously. And we don't need it in Shenandoah > code, because os::protect_memory does the OS-specific stuff for us. > > $ hg diff > diff -r e17250b1955f src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp > --- a/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Tue Mar 21 21:34:20 > 2017 +0100 > +++ b/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Tue Mar 21 21:35:08 > 2017 +0100 > @@ -126,8 +126,6 @@ > #endif > } > > -#include > - > #ifdef ASSERT > > void ShenandoahHeapRegion::memProtectionOn() { > > > Testing: hotspot_gc_shenandoah > > -Aleksey > Yup. Roman From ashipile at redhat.com Tue Mar 21 20:47:15 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 20:47:15 +0000 Subject: hg: shenandoah/jdk9/hotspot: Remove stray include mman.h. Message-ID: <201703212047.v2LKlFVG024521@aojmv0008.oracle.com> Changeset: 240825262ade Author: shade Date: 2017-03-21 21:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/240825262ade Remove stray include mman.h. ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp From ashipile at redhat.com Tue Mar 21 20:47:20 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 20:47:20 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Remove stray include mman.h. Message-ID: <201703212047.v2LKlKEA024612@aojmv0008.oracle.com> Changeset: b2cae915c5af Author: shade Date: 2017-03-21 21:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/b2cae915c5af Remove stray include mman.h. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp From shade at redhat.com Tue Mar 21 21:31:57 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Mar 2017 22:31:57 +0100 Subject: RFR: 9+8u: BrooksPointer::(word|byte)_size should be uint Message-ID: <88374442-efcd-2fa1-8b28-7399b0e3dc94@redhat.com> Hi, BrooksPointer::(word|byte)_size are now implemented as size_t, which makes compilers think they overflow int expressions. We know these are small values, so we can declare them to be uint. New asserts are added to check the are indeed positive. A few places around their uses fixed too. Fix: http://cr.openjdk.java.net/~shade/shenandoah/brooks-uints/webrev.01/ Same thing goes to 8u. Testing: hotspot_gc_shenandoah on 9 and 8u. Thanks, -Aleksey From rkennke at redhat.com Tue Mar 21 21:44:49 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Mar 2017 22:44:49 +0100 Subject: RFR: 9+8u: BrooksPointer::(word|byte)_size should be uint In-Reply-To: <88374442-efcd-2fa1-8b28-7399b0e3dc94@redhat.com> References: <88374442-efcd-2fa1-8b28-7399b0e3dc94@redhat.com> Message-ID: <7dcc241e-1519-d83c-7553-09bc4abaa9dc@redhat.com> Am 21.03.2017 um 22:31 schrieb Aleksey Shipilev: > Hi, > > BrooksPointer::(word|byte)_size are now implemented as size_t, which makes > compilers think they overflow int expressions. We know these are small values, > so we can declare them to be uint. New asserts are added to check the are indeed > positive. A few places around their uses fixed too. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/brooks-uints/webrev.01/ > > Same thing goes to 8u. > > Testing: hotspot_gc_shenandoah on 9 and 8u. > > Thanks, > -Aleksey > ok From ashipile at redhat.com Tue Mar 21 21:48:09 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 21:48:09 +0000 Subject: hg: shenandoah/jdk9/hotspot: BrooksPointer::(word|byte)_size should be uint. Message-ID: <201703212148.v2LLm9DE010421@aojmv0008.oracle.com> Changeset: 97aced46ce30 Author: shade Date: 2017-03-21 22:47 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/97aced46ce30 BrooksPointer::(word|byte)_size should be uint. ! src/share/vm/gc/shenandoah/brooksPointer.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp From ashipile at redhat.com Tue Mar 21 21:48:16 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 21 Mar 2017 21:48:16 +0000 Subject: hg: shenandoah/jdk8u/hotspot: BrooksPointer::(word|byte)_size should be uint. Message-ID: <201703212148.v2LLmHV4010496@aojmv0008.oracle.com> Changeset: 4e626741c506 Author: shade Date: 2017-03-21 22:47 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/4e626741c506 BrooksPointer::(word|byte)_size should be uint. ! src/share/vm/gc_implementation/shenandoah/brooksPointer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp From shade at redhat.com Wed Mar 22 08:06:38 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 09:06:38 +0100 Subject: RFR: Clean up more uint -> size_t, int -> uint uses Message-ID: <48aaac5e-d685-95a0-699f-21c2f46a642f@redhat.com> Hi, Another one for 9: http://cr.openjdk.java.net/~shade/shenandoah/build/more-casts/webrev.01/ Testing: hotspot_gc_shenandoah for 9. Thanks, -Aleksey From rkennke at redhat.com Wed Mar 22 09:47:59 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Mar 2017 10:47:59 +0100 Subject: RFR: Clean up more uint -> size_t, int -> uint uses In-Reply-To: <48aaac5e-d685-95a0-699f-21c2f46a642f@redhat.com> References: <48aaac5e-d685-95a0-699f-21c2f46a642f@redhat.com> Message-ID: Am 22.03.2017 um 09:06 schrieb Aleksey Shipilev: > Hi, > > Another one for 9: > http://cr.openjdk.java.net/~shade/shenandoah/build/more-casts/webrev.01/ > > Testing: hotspot_gc_shenandoah for 9. > > Thanks, > -Aleksey > Ok From shade at redhat.com Wed Mar 22 09:49:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 10:49:50 +0100 Subject: RFR: Turn ShenandoahHeapRegion::{Size,Shift} into the type-checked getters Message-ID: Hi, We have lots of cases where we downcast ShenandoahHeapRegion::{Size,Shift} to jint. While this is probably safe in most cases, compilers complain, and don't let us build. This introduces the type-checked getters, and changes all uses appropriately: http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-getters/webrev.01/ Testing: hotspot_gc_shenandoah Thanks, -Aleksey From roman at kennke.org Wed Mar 22 09:58:00 2017 From: roman at kennke.org (Roman Kennke) Date: Wed, 22 Mar 2017 10:58:00 +0100 Subject: RFR: Turn ShenandoahHeapRegion::{Size, Shift} into the type-checked getters In-Reply-To: References: Message-ID: Ok Am 22. M?rz 2017 10:49:50 MEZ schrieb Aleksey Shipilev : >Hi, > >We have lots of cases where we downcast >ShenandoahHeapRegion::{Size,Shift} to >jint. While this is probably safe in most cases, compilers complain, >and don't >let us build. This introduces the type-checked getters, and changes all >uses >appropriately: >http://cr.openjdk.java.net/~shade/shenandoah/regionsizes-getters/webrev.01/ > >Testing: hotspot_gc_shenandoah > >Thanks, >-Aleksey -- Sent from my FairPhone From shade at redhat.com Wed Mar 22 09:58:46 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 10:58:46 +0100 Subject: RFR: ShenandoahSupport: fix precedence and opcode check Message-ID: Hi Roland, MSVC found these pitfalls: diff -r 97aced46ce30 src/share/vm/opto/shenandoahSupport.cpp --- a/src/share/vm/opto/shenandoahSupport.cpp Tue Mar 21 22:47:25 2017 +0100 +++ b/src/share/vm/opto/shenandoahSupport.cpp Wed Mar 22 10:36:59 2017 +0100 @@ -21,6 +21,7 @@ * */ +#include "precompiled.hpp" #include "gc/shenandoah/brooksPointer.hpp" #include "gc/shenandoah/shenandoahHeap.hpp" #include "gc/shenandoah/shenandoahHeapRegion.hpp" @@ -413,7 +414,7 @@ bool ShenandoahWriteBarrierNode::is_evacuation_in_progress_test(Node* iff) { assert(iff->is_If(), "bad input"); - if (!iff->Opcode() == Op_If) { + if (iff->Opcode() != Op_If) { return false; } Node* bol = iff->in(1); @@ -2080,7 +2081,7 @@ if (ctrl->is_Proj() && ctrl->in(0)->is_Call() && ctrl->unique_ctrl_out() != NULL && - ctrl->unique_ctrl_out()->Opcode() == Op_Catch & + ctrl->unique_ctrl_out()->Opcode() == Op_Catch && !phase->is_dominator(val_ctrl, ctrl->in(0)->in(0))) { continue; } Do you agree with the fixes? Thanks, -Aleksey From ashipile at redhat.com Wed Mar 22 10:00:38 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 10:00:38 +0000 Subject: hg: shenandoah/jdk9/hotspot: Turn ShenandoahHeapRegion::{Size, Shift} into the type-checked getters. Message-ID: <201703221000.v2MA0cOg003821@aojmv0008.oracle.com> Changeset: 66bdbc6d6b21 Author: shade Date: 2017-03-22 10:59 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/66bdbc6d6b21 Turn ShenandoahHeapRegion::{Size,Shift} into the type-checked getters. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc/shenandoah/shenandoahHumongous.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/shenandoahSupport.cpp From rwestrel at redhat.com Wed Mar 22 10:01:15 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 22 Mar 2017 11:01:15 +0100 Subject: RFR: ShenandoahSupport: fix precedence and opcode check In-Reply-To: References: Message-ID: > MSVC found these pitfalls: That looks good to me. Thanks for fixing them. Roland. From ashipile at redhat.com Wed Mar 22 10:05:56 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 10:05:56 +0000 Subject: hg: shenandoah/jdk9/hotspot: ShenandoahSupport: fix precedence and opcode check. Message-ID: <201703221005.v2MA5urv006003@aojmv0008.oracle.com> Changeset: a1af3157e9cf Author: shade Date: 2017-03-22 11:05 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a1af3157e9cf ShenandoahSupport: fix precedence and opcode check. ! src/share/vm/opto/shenandoahSupport.cpp From shade at redhat.com Wed Mar 22 10:42:48 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 11:42:48 +0100 Subject: RFR: No variable-length arrays in standard C++ Message-ID: <5eacc5db-8026-ca92-2bf1-5351e65e82ea@redhat.com> Hi, We use variable-length arrays in two places in GC code. This is not standard C++, however. GCC has this extension and thus compiles fine, while MSVC fails. Fix: http://cr.openjdk.java.net/~shade/shenandoah/no-vla/webrev.01 Testing: hotspot_gc_shenandoah for 9 and 8u Thanks, -Aleksey From roman at kennke.org Wed Mar 22 10:54:23 2017 From: roman at kennke.org (Roman Kennke) Date: Wed, 22 Mar 2017 11:54:23 +0100 Subject: RFR: No variable-length arrays in standard C++ In-Reply-To: <5eacc5db-8026-ca92-2bf1-5351e65e82ea@redhat.com> References: <5eacc5db-8026-ca92-2bf1-5351e65e82ea@redhat.com> Message-ID: Yup Am 22. M?rz 2017 11:42:48 MEZ schrieb Aleksey Shipilev : >Hi, > >We use variable-length arrays in two places in GC code. This is not >standard >C++, however. GCC has this extension and thus compiles fine, while MSVC >fails. Fix: > http://cr.openjdk.java.net/~shade/shenandoah/no-vla/webrev.01 > >Testing: hotspot_gc_shenandoah for 9 and 8u > >Thanks, >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Wed Mar 22 11:00:41 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:00:41 +0000 Subject: hg: shenandoah/jdk9/hotspot: No variable-length arrays in standard C++. Message-ID: <201703221100.v2MB0fR7018457@aojmv0008.oracle.com> Changeset: 2e17f4bfa629 Author: shade Date: 2017-03-22 12:00 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/2e17f4bfa629 No variable-length arrays in standard C++. ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp From ashipile at redhat.com Wed Mar 22 11:05:13 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:05:13 +0000 Subject: hg: shenandoah/jdk8u/hotspot: No variable-length arrays in standard C++. Message-ID: <201703221105.v2MB5DVS020479@aojmv0008.oracle.com> Changeset: dc28bfc16c94 Author: shade Date: 2017-03-22 12:04 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/dc28bfc16c94 No variable-length arrays in standard C++. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp From ashipile at redhat.com Wed Mar 22 11:30:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:30:11 +0000 Subject: hg: shenandoah/jdk9/hotspot: Clean up more uint -> size_t, int -> uint, int -> jint uses. Message-ID: <201703221130.v2MBUBNK026017@aojmv0008.oracle.com> Changeset: ff480ec92605 Author: shade Date: 2017-03-22 12:29 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ff480ec92605 Clean up more uint -> size_t, int -> uint, int -> jint uses. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp ! src/share/vm/opto/graphKit.cpp From ashipile at redhat.com Wed Mar 22 11:38:17 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:38:17 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add missing precompiled.hpp to Shenandoah files, #2. Message-ID: <201703221138.v2MBcHpv028698@aojmv0008.oracle.com> Changeset: 0faa7161268f Author: shade Date: 2017-03-22 12:37 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/0faa7161268f Add missing precompiled.hpp to Shenandoah files, #2. ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/share/vm/gc/shared/cmBitMap.cpp ! src/share/vm/gc/shared/parallelCleaning.cpp ! src/share/vm/services/shenandoahMemoryPool.cpp From ashipile at redhat.com Wed Mar 22 11:42:33 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:42:33 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Wrap log_develop_trace in block to make compiler happy. Message-ID: <201703221142.v2MBgYlM029676@aojmv0008.oracle.com> Changeset: e4c9e6692213 Author: shade Date: 2017-03-22 12:40 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/e4c9e6692213 Wrap log_develop_trace in block to make compiler happy. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp From ashipile at redhat.com Wed Mar 22 11:42:33 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:42:33 +0000 Subject: hg: shenandoah/jdk9/hotspot: Wrap log_develop_trace in block to make compiler happy. Message-ID: <201703221142.v2MBgXSI029673@aojmv0008.oracle.com> Changeset: 6423e664e66a Author: shade Date: 2017-03-22 12:40 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/6423e664e66a Wrap log_develop_trace in block to make compiler happy. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From shade at redhat.com Wed Mar 22 11:54:51 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 12:54:51 +0100 Subject: RFR: 9+8u: Windows expects "long long" constant in macroAssembler Message-ID: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> $ hg diff diff -r 6423e664e66a src/share/vm/asm/assembler.cpp --- a/src/share/vm/asm/assembler.cpp Wed Mar 22 12:40:47 2017 +0100 +++ b/src/share/vm/asm/assembler.cpp Wed Mar 22 12:52:22 2017 +0100 @@ -322,7 +322,11 @@ // AArch64 uses 48-bit addresses const unsigned long address_bits = 0xfffffffffffful; #elif defined(_LP64) +#ifdef _WINDOWS + const unsigned long long address_bits = 0xffffffffffffffffull; +#else const unsigned long address_bits = 0xfffffffffffffffful; +#endif // _WINDOWS #else // Shenandoah is not implemented on these platforms, make sure we build fine, // but also crash consistently at runtime. Testing: hotspot_gc_shenandoah for 9 and 8u. Thanks, -Aleksey From roman at kennke.org Wed Mar 22 11:55:22 2017 From: roman at kennke.org (Roman Kennke) Date: Wed, 22 Mar 2017 12:55:22 +0100 Subject: RFR: 9+8u: Windows expects "long long" constant in macroAssembler In-Reply-To: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> Message-ID: <0C1816DB-2600-4F94-8CF7-1417F6293E8F@kennke.org> Ja! Am 22. M?rz 2017 12:54:51 MEZ schrieb Aleksey Shipilev : >$ hg diff >diff -r 6423e664e66a src/share/vm/asm/assembler.cpp >--- a/src/share/vm/asm/assembler.cpp Wed Mar 22 12:40:47 2017 +0100 >+++ b/src/share/vm/asm/assembler.cpp Wed Mar 22 12:52:22 2017 +0100 >@@ -322,7 +322,11 @@ > // AArch64 uses 48-bit addresses > const unsigned long address_bits = 0xfffffffffffful; > #elif defined(_LP64) >+#ifdef _WINDOWS >+ const unsigned long long address_bits = 0xffffffffffffffffull; >+#else > const unsigned long address_bits = 0xfffffffffffffffful; >+#endif // _WINDOWS > #else >// Shenandoah is not implemented on these platforms, make sure we build >fine, > // but also crash consistently at runtime. > > >Testing: hotspot_gc_shenandoah for 9 and 8u. > >Thanks, >-Aleksey -- Sent from my FairPhone From ashipile at redhat.com Wed Mar 22 11:57:37 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:57:37 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Windows expects "long long" constant in macroAssembler. Message-ID: <201703221157.v2MBvbC2003595@aojmv0008.oracle.com> Changeset: 77e5b4b59e26 Author: shade Date: 2017-03-22 12:56 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/77e5b4b59e26 Windows expects "long long" constant in macroAssembler. ! src/share/vm/asm/assembler.cpp From ashipile at redhat.com Wed Mar 22 11:57:45 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 11:57:45 +0000 Subject: hg: shenandoah/jdk9/hotspot: Windows expects "long long" constant in macroAssembler. Message-ID: <201703221157.v2MBvkc7003662@aojmv0008.oracle.com> Changeset: 3cc84cf44c98 Author: shade Date: 2017-03-22 12:57 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/3cc84cf44c98 Windows expects "long long" constant in macroAssembler. ! src/share/vm/asm/assembler.cpp From rkennke at redhat.com Wed Mar 22 12:03:18 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Mar 2017 13:03:18 +0100 Subject: RFR: 9+8u: Windows expects "long long" constant in macroAssembler In-Reply-To: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> Message-ID: <09880362-bb92-d141-1bce-859f0ecb614a@redhat.com> I think it's ok if you push all those little compilation fixes without review, unless you're not sure about something. Roman Am 22.03.2017 um 12:54 schrieb Aleksey Shipilev: > $ hg diff > diff -r 6423e664e66a src/share/vm/asm/assembler.cpp > --- a/src/share/vm/asm/assembler.cpp Wed Mar 22 12:40:47 2017 +0100 > +++ b/src/share/vm/asm/assembler.cpp Wed Mar 22 12:52:22 2017 +0100 > @@ -322,7 +322,11 @@ > // AArch64 uses 48-bit addresses > const unsigned long address_bits = 0xfffffffffffful; > #elif defined(_LP64) > +#ifdef _WINDOWS > + const unsigned long long address_bits = 0xffffffffffffffffull; > +#else > const unsigned long address_bits = 0xfffffffffffffffful; > +#endif // _WINDOWS > #else > // Shenandoah is not implemented on these platforms, make sure we build fine, > // but also crash consistently at runtime. > > > Testing: hotspot_gc_shenandoah for 9 and 8u. > > Thanks, > -Aleksey > From shade at redhat.com Wed Mar 22 12:04:30 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 13:04:30 +0100 Subject: RFR: 9+8u: Windows expects "long long" constant in macroAssembler In-Reply-To: <09880362-bb92-d141-1bce-859f0ecb614a@redhat.com> References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> <09880362-bb92-d141-1bce-859f0ecb614a@redhat.com> Message-ID: <9d9bf5be-b6ff-c92a-cc95-1f1056748dc7@redhat.com> On 03/22/2017 01:03 PM, Roman Kennke wrote: > I think it's ok if you push all those little compilation fixes without > review, unless you're not sure about something. I'm just juggling lots of these things, it feels safer for me to have another pair of eyes to watch my back. I would not RFR simple backports. -Aleksey From ashipile at redhat.com Wed Mar 22 12:32:00 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 12:32:00 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix fastdebug build failures due to missed uint->size_t update. Message-ID: <201703221232.v2MCW0Dj019356@aojmv0008.oracle.com> Changeset: e47c065a8cbb Author: shade Date: 2017-03-22 13:31 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e47c065a8cbb Fix fastdebug build failures due to missed uint->size_t update. ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.inline.hpp From aph at redhat.com Wed Mar 22 12:43:49 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Mar 2017 12:43:49 +0000 Subject: RFR: 9+8u: Windows expects "long long" constant in macroAssembler In-Reply-To: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> Message-ID: <9313f828-21ce-21f9-9a1d-4b06bedae278@redhat.com> On 22/03/17 11:54, Aleksey Shipilev wrote: > #elif defined(_LP64) > +#ifdef _WINDOWS > + const unsigned long long address_bits = 0xffffffffffffffffull; > +#else > const unsigned long address_bits = 0xfffffffffffffffful; > +#endif // _WINDOWS > #else I'd use uintptr_t address_bits = ~(unitptr_t)0; Andrew. From rkennke at redhat.com Wed Mar 22 15:16:28 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Mar 2017 16:16:28 +0100 Subject: RFR: Clear outgoing matrix for root regions during preparation phase Message-ID: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> We're currently clearing the outgoing matrix for root regions during the collection phase of partial GC. I find it more natural to do it in the preparation phase. While it's not per-se incorrect (only one thread should have to do with each root region at a time), I'm a bit uneasy to have threads clearing whole rows, while other threads are updating the matrix. They *should* not collide, but I'll sleep better if we could just do it during preparation. It also means to move verification up before preparation, because otherwise whole rows will be cleared. http://cr.openjdk.java.net/~rkennke/cleanmatrix/webrev.00/ Roman From rkennke at redhat.com Wed Mar 22 15:25:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Mar 2017 16:25:07 +0100 Subject: RFR: Use constant template arg to build matrix/no-matrix version of partial GC process_oop() Message-ID: as $SUBJECT says. should save a few cycles to decide whether or not we need to update the matrix (which we know at compile-time). BTW: C++11 has a nice feature. With C++11 we could declare bool update_matrix as constexpr, which, as far as I understand it, would do the same as a template arg. (And save us this whole currying mess that we have in conc mark...) http://cr.openjdk.java.net/~rkennke/templ_proc_oop/webrev.00/ Roman From shade at redhat.com Wed Mar 22 15:33:53 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 16:33:53 +0100 Subject: RFR: Clear outgoing matrix for root regions during preparation phase In-Reply-To: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> References: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> Message-ID: <7ada2a12-26bd-3425-67c9-80fe176b1173@redhat.com> On 03/22/2017 04:16 PM, Roman Kennke wrote: > We're currently clearing the outgoing matrix for root regions during the > collection phase of partial GC. I find it more natural to do it in the > preparation phase. While it's not per-se incorrect (only one thread > should have to do with each root region at a time), I'm a bit uneasy to > have threads clearing whole rows, while other threads are updating the > matrix. They *should* not collide, but I'll sleep better if we could > just do it during preparation. It also means to move verification up > before preparation, because otherwise whole rows will be cleared. > > http://cr.openjdk.java.net/~rkennke/cleanmatrix/webrev.00/ Yes, I was wondering about the same. Looks good. -Aleksey From shade at redhat.com Wed Mar 22 15:35:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 16:35:06 +0100 Subject: RFR: Use constant template arg to build matrix/no-matrix version of partial GC process_oop() In-Reply-To: References: Message-ID: <639d64d4-bab8-1d4e-24c0-856be0ed8d49@redhat.com> On 03/22/2017 04:25 PM, Roman Kennke wrote: > as $SUBJECT says. should save a few cycles to decide whether or not we > need to update the matrix (which we know at compile-time). > > BTW: C++11 has a nice feature. With C++11 we could declare bool > update_matrix as constexpr, which, as far as I understand it, would do > the same as a template arg. (And save us this whole currying mess that > we have in conc mark...) > > http://cr.openjdk.java.net/~rkennke/templ_proc_oop/webrev.00/ Makes sense. Go! -Aleksey From zgu at redhat.com Wed Mar 22 15:35:55 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 Mar 2017 11:35:55 -0400 Subject: RFR: Clear outgoing matrix for root regions during preparation phase In-Reply-To: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> References: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> Message-ID: Would it be better to the clear outbound matrix during building the root set? -Zhengyu On 03/22/2017 11:16 AM, Roman Kennke wrote: > We're currently clearing the outgoing matrix for root regions during the > collection phase of partial GC. I find it more natural to do it in the > preparation phase. While it's not per-se incorrect (only one thread > should have to do with each root region at a time), I'm a bit uneasy to > have threads clearing whole rows, while other threads are updating the > matrix. They *should* not collide, but I'll sleep better if we could > just do it during preparation. It also means to move verification up > before preparation, because otherwise whole rows will be cleared. > > http://cr.openjdk.java.net/~rkennke/cleanmatrix/webrev.00/ > > > Roman > > From roman at kennke.org Wed Mar 22 15:39:06 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 22 Mar 2017 15:39:06 +0000 Subject: hg: shenandoah/jdk9/hotspot: 2 new changesets Message-ID: <201703221539.v2MFd67q008755@aojmv0008.oracle.com> Changeset: 1f9761c54602 Author: rkennke Date: 2017-03-22 16:12 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/1f9761c54602 Clear outgoing matrix for root regions during preparation phase. ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp Changeset: fb5142b3ae3c Author: rkennke Date: 2017-03-22 16:21 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/fb5142b3ae3c Use constant template arg to build matrix/no-matrix version of partial GC process_oop(). ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.hpp From rkennke at redhat.com Wed Mar 22 15:44:48 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Mar 2017 16:44:48 +0100 Subject: RFR: Clear outgoing matrix for root regions during preparation phase In-Reply-To: References: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> Message-ID: Good question. I don't think so, because we'd be messing with the matrix for regions we're likely to look at. While it probably wouldn't clash, I find it easier to convince myself if it happens in a separate pass. That's why I hooked it up on the last pass. Roman Am 22.03.2017 um 16:35 schrieb Zhengyu Gu: > Would it be better to the clear outbound matrix during building the > root set? > > -Zhengyu > > On 03/22/2017 11:16 AM, Roman Kennke wrote: >> We're currently clearing the outgoing matrix for root regions during the >> collection phase of partial GC. I find it more natural to do it in the >> preparation phase. While it's not per-se incorrect (only one thread >> should have to do with each root region at a time), I'm a bit uneasy to >> have threads clearing whole rows, while other threads are updating the >> matrix. They *should* not collide, but I'll sleep better if we could >> just do it during preparation. It also means to move verification up >> before preparation, because otherwise whole rows will be cleared. >> >> http://cr.openjdk.java.net/~rkennke/cleanmatrix/webrev.00/ >> >> >> Roman >> >> From zgu at redhat.com Wed Mar 22 15:48:35 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 Mar 2017 11:48:35 -0400 Subject: RFR: Clear outgoing matrix for root regions during preparation phase In-Reply-To: References: <492d2a21-37ad-3a98-e423-bcde49389efb@redhat.com> Message-ID: Got it. Thanks, -Zhengyu On 03/22/2017 11:44 AM, Roman Kennke wrote: > Good question. I don't think so, because we'd be messing with the matrix > for regions we're likely to look at. While it probably wouldn't clash, I > find it easier to convince myself if it happens in a separate pass. > That's why I hooked it up on the last pass. > > Roman > > Am 22.03.2017 um 16:35 schrieb Zhengyu Gu: >> Would it be better to the clear outbound matrix during building the >> root set? >> >> -Zhengyu >> >> On 03/22/2017 11:16 AM, Roman Kennke wrote: >>> We're currently clearing the outgoing matrix for root regions during the >>> collection phase of partial GC. I find it more natural to do it in the >>> preparation phase. While it's not per-se incorrect (only one thread >>> should have to do with each root region at a time), I'm a bit uneasy to >>> have threads clearing whole rows, while other threads are updating the >>> matrix. They *should* not collide, but I'll sleep better if we could >>> just do it during preparation. It also means to move verification up >>> before preparation, because otherwise whole rows will be cleared. >>> >>> http://cr.openjdk.java.net/~rkennke/cleanmatrix/webrev.00/ >>> >>> >>> Roman >>> >>> > > From ashipile at redhat.com Wed Mar 22 16:18:50 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 16:18:50 +0000 Subject: hg: shenandoah/jdk8u/hotspot: ObjChunkedArrayTask enum constants overflow. Message-ID: <201703221618.v2MGIoWf019756@aojmv0008.oracle.com> Changeset: 0e7d54f61e25 Author: shade Date: 2017-03-22 17:18 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0e7d54f61e25 ObjChunkedArrayTask enum constants overflow. ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp ! src/share/vm/runtime/arguments.cpp From ashipile at redhat.com Wed Mar 22 16:45:59 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 16:45:59 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Use size_t consistently for region sizes, counts. Message-ID: <201703221646.v2MGjx6h026952@aojmv0008.oracle.com> Changeset: 61a20f31dcae Author: shade Date: 2017-03-22 17:45 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/61a20f31dcae Use size_t consistently for region sizes, counts. ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp From ashipile at redhat.com Wed Mar 22 16:59:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 16:59:11 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Turn ShenandoahHeapRegion::{Size, Shift} into the type-checked getters. Message-ID: <201703221659.v2MGxBXl000307@aojmv0008.oracle.com> Changeset: ae0f8360a5f1 Author: shade Date: 2017-03-22 17:58 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/ae0f8360a5f1 Turn ShenandoahHeapRegion::{Size,Shift} into the type-checked getters. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHumongous.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/opto/shenandoahSupport.cpp From ashipile at redhat.com Wed Mar 22 17:14:06 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 17:14:06 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Clean up more uint -> size_t, int -> uint, int -> jint uses. Message-ID: <201703221714.v2MHE6rd004113@aojmv0008.oracle.com> Changeset: af601c570f33 Author: shade Date: 2017-03-22 18:13 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/af601c570f33 Clean up more uint -> size_t, int -> uint, int -> jint uses. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp From ashipile at redhat.com Wed Mar 22 17:31:47 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 17:31:47 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Disable MSVC 4522, as taskqueue.hpp does. Message-ID: <201703221731.v2MHVlT7009463@aojmv0008.oracle.com> Changeset: 4d8b88500670 Author: shade Date: 2017-03-22 18:30 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/4d8b88500670 Disable MSVC 4522, as taskqueue.hpp does. ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp From chf at redhat.com Wed Mar 22 18:30:49 2017 From: chf at redhat.com (Christine Flood) Date: Wed, 22 Mar 2017 14:30:49 -0400 Subject: RFR: Turn PrintShenandoahMatrix back on. Message-ID: http://cr.openjdk.java.net/~chf/printMatrix.00/ From shade at redhat.com Wed Mar 22 18:33:19 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 19:33:19 +0100 Subject: RFR: Turn PrintShenandoahMatrix back on. In-Reply-To: References: Message-ID: <1d5559d5-a763-6890-5b11-7cd2f8dc8a9e@redhat.com> On 03/22/2017 07:30 PM, Christine Flood wrote: > http://cr.openjdk.java.net/~chf/printMatrix.00/ Looks good. Should probably be (UseShenandoahMatrix && PrintShenandoahMatrix) for consistency, regardless of the fact that partial only works with matrix. -Aleksey From shade at redhat.com Wed Mar 22 18:34:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Mar 2017 19:34:34 +0100 Subject: RFR: Turn PrintShenandoahMatrix back on. In-Reply-To: <1d5559d5-a763-6890-5b11-7cd2f8dc8a9e@redhat.com> References: <1d5559d5-a763-6890-5b11-7cd2f8dc8a9e@redhat.com> Message-ID: <4affa8dd-c3f7-c8b7-24b0-8d3aa5e429de@redhat.com> On 03/22/2017 07:33 PM, Aleksey Shipilev wrote: > On 03/22/2017 07:30 PM, Christine Flood wrote: >> http://cr.openjdk.java.net/~chf/printMatrix.00/ > > Looks good. Should probably be (UseShenandoahMatrix && PrintShenandoahMatrix) > for consistency, regardless of the fact that partial only works with matrix. Also, printed to gc log, as in other places. if (UseShenandoahMatrix && PrintShenandoahMatrix) { outputStream* log = Log(gc)::info_stream(); _heap->connection_matrix()->print_on(log); } -Aleksey From ashipile at redhat.com Wed Mar 22 19:25:58 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 19:25:58 +0000 Subject: hg: shenandoah/jdk8u/hotspot: 2 new changesets Message-ID: <201703221925.v2MJPwRS011293@aojmv0008.oracle.com> Changeset: 5226488706ef Author: shade Date: 2017-03-22 20:24 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/5226488706ef Add missing precompiled.hpp to Shenandoah files, #2. ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/share/vm/gc_implementation/shared/parallelCleaning.cpp ! src/share/vm/services/shenandoahMemoryPool.cpp Changeset: e510c37a1611 Author: shade Date: 2017-03-22 20:25 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/e510c37a1611 ShenandoahSupport: fix precedence and opcode check. ! src/share/vm/opto/shenandoahSupport.cpp From ashipile at redhat.com Wed Mar 22 19:32:54 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 19:32:54 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Hook up Shenandoah to Windows build list. Message-ID: <201703221932.v2MJWsC7013679@aojmv0008.oracle.com> Changeset: 0b236e757969 Author: shade Date: 2017-03-22 20:32 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0b236e757969 Hook up Shenandoah to Windows build list. ! make/excludeSrc.make ! make/windows/makefiles/vm.make From ashipile at redhat.com Wed Mar 22 19:39:29 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 19:39:29 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Make MSVC 2010 happy by spelling out (un)signess. Message-ID: <201703221939.v2MJdTFA016636@aojmv0008.oracle.com> Changeset: a905fc669e5e Author: shade Date: 2017-03-22 20:38 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a905fc669e5e Make MSVC 2010 happy by spelling out (un)signess. ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/runtime/arguments.cpp From ashipile at redhat.com Wed Mar 22 19:49:44 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 22 Mar 2017 19:49:44 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix non-LP64 version of ObjArrayChunkedTask. Message-ID: <201703221949.v2MJnjNS020109@aojmv0008.oracle.com> Changeset: 72aac529caea Author: shade Date: 2017-03-22 20:49 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/72aac529caea Fix non-LP64 version of ObjArrayChunkedTask. ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp From rkennke at redhat.com Thu Mar 23 20:03:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Mar 2017 21:03:13 +0100 Subject: RFR: C1 fixes to matrix barriers Message-ID: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> This fixes a bunch of issues with the matrix barriers in c1: - it needs longConst() for stride, otherwise the register sizes do not match in the mult - AArch64 macro assembler can't work with 64bit immediates in some math ops, I changed it to explicitely load into regs first. X86 moves it to a reg anyway. - AAarch64 can't store a constant 1! I #ifdef'd it to load into register first. Notice that this doesn't make matrix barriers generally work on aarch64, we totally lack the assembler/interpreter impl of the matrix barriers on AArch64. I also added some partial-gc test invocations to GCOld and GCBasher (which first showed the above bugs). http://cr.openjdk.java.net/~rkennke/c1matrixbarrier/webrev.00/ Roman From aph at redhat.com Fri Mar 24 08:20:37 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Mar 2017 08:20:37 +0000 Subject: RFR: C1 fixes to matrix barriers In-Reply-To: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> References: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> Message-ID: On 23/03/17 20:03, Roman Kennke wrote: > This fixes a bunch of issues with the matrix barriers in c1: > > - it needs longConst() for stride, otherwise the register sizes do not > match in the mult > - AArch64 macro assembler can't work with 64bit immediates in some math > ops, I changed it to explicitely load into regs first. X86 moves it to a > reg anyway. > - AAarch64 can't store a constant 1! I #ifdef'd it to load into register > first. What is this for? +#ifdef AARCH64 + // Aarch64 cannot (yet) move a constant 1 ... + LIR_Opr one = new_register(T_INT); + __ move(LIR_OprFact::intConst(1), one); +#else + LIR_Opr one = LIR_OprFact::intConst(1); +#endif + __ move(one, matrix_elem_addr); Surely a register move works everywhere. Andrew. From rkennke at redhat.com Fri Mar 24 08:29:06 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Mar 2017 09:29:06 +0100 Subject: RFR: C1 fixes to matrix barriers In-Reply-To: References: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> Message-ID: <9ca8fd7f-8cd6-d8f1-1994-6b0b132d8b73@redhat.com> Am 24.03.2017 um 09:20 schrieb Andrew Haley: > On 23/03/17 20:03, Roman Kennke wrote: >> This fixes a bunch of issues with the matrix barriers in c1: >> >> - it needs longConst() for stride, otherwise the register sizes do not >> match in the mult >> - AArch64 macro assembler can't work with 64bit immediates in some math >> ops, I changed it to explicitely load into regs first. X86 moves it to a >> reg anyway. >> - AAarch64 can't store a constant 1! I #ifdef'd it to load into register >> first. > What is this for? > > +#ifdef AARCH64 > + // Aarch64 cannot (yet) move a constant 1 ... > + LIR_Opr one = new_register(T_INT); > + __ move(LIR_OprFact::intConst(1), one); > +#else > + LIR_Opr one = LIR_OprFact::intConst(1); > +#endif > + __ move(one, matrix_elem_addr); > > Surely a register move works everywhere. Yeah, but x86 can move an immediate instead, no need to take a register there. AArch64's const2mem() would only move a zero. Roman From aph at redhat.com Fri Mar 24 08:55:38 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Mar 2017 08:55:38 +0000 Subject: RFR: C1 fixes to matrix barriers In-Reply-To: <9ca8fd7f-8cd6-d8f1-1994-6b0b132d8b73@redhat.com> References: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> <9ca8fd7f-8cd6-d8f1-1994-6b0b132d8b73@redhat.com> Message-ID: <50ec919c-890e-8081-cfb5-72fe208a5019@redhat.com> On 24/03/17 08:29, Roman Kennke wrote: > Yeah, but x86 can move an immediate instead, no need to take a register > there. > AArch64's const2mem() would only move a zero. And this is worth splattering #ifdefs over shared code? And there is a speed gain? In C1? Andrew. From rkennke at redhat.com Fri Mar 24 09:21:43 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Mar 2017 10:21:43 +0100 Subject: RFR: C1 fixes to matrix barriers In-Reply-To: <50ec919c-890e-8081-cfb5-72fe208a5019@redhat.com> References: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> <9ca8fd7f-8cd6-d8f1-1994-6b0b132d8b73@redhat.com> <50ec919c-890e-8081-cfb5-72fe208a5019@redhat.com> Message-ID: Am 24.03.2017 um 09:55 schrieb Andrew Haley: > On 24/03/17 08:29, Roman Kennke wrote: >> Yeah, but x86 can move an immediate instead, no need to take a register >> there. >> AArch64's const2mem() would only move a zero. > And this is worth splattering #ifdefs over shared code? And there > is a speed gain? In C1? Hmm, right. No. http://cr.openjdk.java.net/~rkennke/c1matrixbarrier/webrev.01/ Better? Roman From aph at redhat.com Fri Mar 24 09:27:21 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Mar 2017 09:27:21 +0000 Subject: RFR: C1 fixes to matrix barriers In-Reply-To: References: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> <9ca8fd7f-8cd6-d8f1-1994-6b0b132d8b73@redhat.com> <50ec919c-890e-8081-cfb5-72fe208a5019@redhat.com> Message-ID: <82ea2077-267e-28a8-287d-a324d972c300@redhat.com> On 24/03/17 09:21, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/c1matrixbarrier/webrev.01/ > > > Better? :-) Andrew. From shade at redhat.com Fri Mar 24 11:01:32 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Mar 2017 12:01:32 +0100 Subject: RFR: C1 fixes to matrix barriers In-Reply-To: References: <94778f05-483b-20ec-3392-b8081c67a994@redhat.com> <9ca8fd7f-8cd6-d8f1-1994-6b0b132d8b73@redhat.com> <50ec919c-890e-8081-cfb5-72fe208a5019@redhat.com> Message-ID: On 03/24/2017 10:21 AM, Roman Kennke wrote: > Am 24.03.2017 um 09:55 schrieb Andrew Haley: >> On 24/03/17 08:29, Roman Kennke wrote: >>> Yeah, but x86 can move an immediate instead, no need to take a register >>> there. >>> AArch64's const2mem() would only move a zero. >> And this is worth splattering #ifdefs over shared code? And there >> is a speed gain? In C1? > Hmm, right. No. > > http://cr.openjdk.java.net/~rkennke/c1matrixbarrier/webrev.01/ > > > Better? Looks good. -Aleksey From roman at kennke.org Fri Mar 24 11:13:46 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 24 Mar 2017 11:13:46 +0000 Subject: hg: shenandoah/jdk9/hotspot: C1 fixes to matrix barriers. Message-ID: <201703241113.v2OBDk98018701@aojmv0008.oracle.com> Changeset: d47f09cff69d Author: rkennke Date: 2017-03-24 10:19 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d47f09cff69d C1 fixes to matrix barriers. ! src/share/vm/c1/c1_LIRGenerator.cpp ! test/gc/stress/TestGCOldWithShenandoah.java ! test/gc/stress/gcbasher/TestGCBasherWithShenandoah.java From chf at redhat.com Fri Mar 24 14:36:28 2017 From: chf at redhat.com (chf at redhat.com) Date: Fri, 24 Mar 2017 14:36:28 +0000 Subject: hg: shenandoah/jdk9/hotspot: Fix Print Matrix Message-ID: <201703241436.v2OEaSVA017957@aojmv0008.oracle.com> Changeset: d47fad978b3d Author: chf Date: 2017-03-24 10:28 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d47fad978b3d Fix Print Matrix ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From chf at redhat.com Fri Mar 24 14:40:01 2017 From: chf at redhat.com (chf at redhat.com) Date: Fri, 24 Mar 2017 14:40:01 +0000 Subject: hg: shenandoah/jdk9/hotspot: fix a boo boo Message-ID: <201703241440.v2OEe1jm018663@aojmv0008.oracle.com> Changeset: 373d92b4ca8c Author: chf Date: 2017-03-24 10:37 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/373d92b4ca8c fix a boo boo ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp From shade at redhat.com Fri Mar 24 17:25:15 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Mar 2017 18:25:15 +0100 Subject: RFR: Disable matrix for good when -UseShenandoahMatrix Message-ID: <97df524f-13ed-47b7-533c-198f9e8db273@redhat.com> Hi, Turns out, clearing matrix is costly, and it sometimes happens during "prepare evac" at final mark pause: [56.054s][info][gc,stats] Prepare Evacuation = 0.22 s (a = 16725 us) (n = 13) (lvls, us = 137, 16992, 17383, 18555, 19583) This fix disables matrix operations for good when matrix is disabled: http://cr.openjdk.java.net/~shade/shenandoah/matrix-disable-for-good/webrev.01/ This returns final mark pauses to normal. We would need to look into fixing this performance pothole for the case the matrix is enabled and needed by GC. Testing: hotspot_gc_shenandoah, benchmarks Thanks, -Aleksey From rkennke at redhat.com Fri Mar 24 17:39:18 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Mar 2017 18:39:18 +0100 Subject: RFR: Disable matrix for good when -UseShenandoahMatrix In-Reply-To: <97df524f-13ed-47b7-533c-198f9e8db273@redhat.com> References: <97df524f-13ed-47b7-533c-198f9e8db273@redhat.com> Message-ID: Am 24.03.2017 um 18:25 schrieb Aleksey Shipilev: > Hi, > > Turns out, clearing matrix is costly, and it sometimes happens during "prepare > evac" at final mark pause: > > [56.054s][info][gc,stats] Prepare Evacuation = 0.22 s > (a = 16725 us) (n = 13) > (lvls, us = 137, 16992, 17383, 18555, 19583) > > > This fix disables matrix operations for good when matrix is disabled: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-disable-for-good/webrev.01/ > > This returns final mark pauses to normal. We would need to look into fixing this > performance pothole for the case the matrix is enabled and needed by GC. > > Testing: hotspot_gc_shenandoah, benchmarks > > Thanks, > -Aleksey > Can we avoid clearing the bitmap if we don't need it and the clear_all()/internal_clear_all() distinction? Other than that, good! Roman From shade at redhat.com Fri Mar 24 17:46:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Mar 2017 18:46:01 +0100 Subject: RFR: Disable matrix for good when -UseShenandoahMatrix In-Reply-To: References: <97df524f-13ed-47b7-533c-198f9e8db273@redhat.com> Message-ID: On 03/24/2017 06:39 PM, Roman Kennke wrote: > Can we avoid clearing the bitmap if we don't need it and the > clear_all()/internal_clear_all() distinction? Yes we can, like this? 39 if (UseShenandoahMatrix) { 40 clear_all(); 41 } http://cr.openjdk.java.net/~shade/shenandoah/matrix-disable-for-good/webrev.02/ Thanks, -Aleksey From rkennke at redhat.com Fri Mar 24 17:52:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Mar 2017 18:52:21 +0100 Subject: RFR: Disable matrix for good when -UseShenandoahMatrix In-Reply-To: References: <97df524f-13ed-47b7-533c-198f9e8db273@redhat.com> Message-ID: Am 24.03.2017 um 18:46 schrieb Aleksey Shipilev: > On 03/24/2017 06:39 PM, Roman Kennke wrote: >> Can we avoid clearing the bitmap if we don't need it and the >> clear_all()/internal_clear_all() distinction? > Yes we can, like this? > > 39 if (UseShenandoahMatrix) { > 40 clear_all(); > 41 } > > http://cr.openjdk.java.net/~shade/shenandoah/matrix-disable-for-good/webrev.02/ > > Thanks, > -Aleksey > Perfect! Roman From ashipile at redhat.com Fri Mar 24 17:54:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 24 Mar 2017 17:54:11 +0000 Subject: hg: shenandoah/jdk9/hotspot: Disable matrix for good when -UseShenandoahMatrix. Message-ID: <201703241754.v2OHsBnB014263@aojmv0008.oracle.com> Changeset: 27244dffda79 Author: shade Date: 2017-03-24 18:53 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/27244dffda79 Disable matrix for good when -UseShenandoahMatrix. ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp From shade at redhat.com Fri Mar 24 18:28:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Mar 2017 19:28:11 +0100 Subject: RFR: Print out garbage and cset data with -Xlog:gc+ergo Message-ID: Hi, I would like to have it in product builds: http://cr.openjdk.java.net/~shade/shenandoah/policy-print-cset/webrev.01/ Prints: [39.903s][info][gc,ergo] GC(21) Total Garbage: 8701M [39.903s][info][gc,ergo] GC(21) Immediate Garbage: 0M, 0 regions [39.903s][info][gc,ergo] GC(21) Garbage to be collected: 760M (8% of total), 152 regions [39.903s][info][gc,ergo] GC(21) Live objects to be evacuated: 455M [39.903s][info][gc,ergo] GC(21) Live/garbage ratio in collected regions: 59% Thanks, -Aleksey From zgu at redhat.com Fri Mar 24 19:05:46 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 24 Mar 2017 15:05:46 -0400 Subject: RFR: Print out garbage and cset data with -Xlog:gc+ergo In-Reply-To: References: Message-ID: <197ada81-7bc7-0907-c10f-eeebcc448861@redhat.com> Look good. -Zhengyu On 03/24/2017 02:28 PM, Aleksey Shipilev wrote: > Hi, > > I would like to have it in product builds: > http://cr.openjdk.java.net/~shade/shenandoah/policy-print-cset/webrev.01/ > > Prints: > > [39.903s][info][gc,ergo] GC(21) Total Garbage: 8701M > [39.903s][info][gc,ergo] GC(21) Immediate Garbage: 0M, 0 regions > [39.903s][info][gc,ergo] GC(21) Garbage to be collected: 760M (8% of total), 152 > regions > [39.903s][info][gc,ergo] GC(21) Live objects to be evacuated: 455M > [39.903s][info][gc,ergo] GC(21) Live/garbage ratio in collected regions: 59% > > > Thanks, > -Aleksey > From ashipile at redhat.com Fri Mar 24 19:25:25 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 24 Mar 2017 19:25:25 +0000 Subject: hg: shenandoah/jdk9/hotspot: Print out garbage and cset data with -Xlog:gc+ergo. Message-ID: <201703241925.v2OJPPq8010009@aojmv0008.oracle.com> Changeset: e9b5ddec456d Author: shade Date: 2017-03-24 20:24 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e9b5ddec456d Print out garbage and cset data with -Xlog:gc+ergo. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From shade at redhat.com Fri Mar 24 20:01:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Mar 2017 21:01:06 +0100 Subject: RFR: Report correct total garbage data Message-ID: gc+ergo reports weird data: [21.336s][info][gc,ergo] GC(3) Total Garbage: 347M [21.336s][info][gc,ergo] GC(3) Immediate Garbage: 216M, 27 regions [21.336s][info][gc,ergo] GC(3) Garbage to be collected: 8072M (2323% of total), 1062 regions [21.336s][info][gc,ergo] GC(3) Live objects to be evacuated: 423M "total garbage" is wrong, because it is polled after cset is constructed. Which excludes all regions from the cset in total garbage calculation. Trivial fix: http://cr.openjdk.java.net/~shade/shenandoah/policy-report-correct-garbage/webrev.01/ Thanks, -Aleksey From rkennke at redhat.com Fri Mar 24 20:38:12 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Mar 2017 21:38:12 +0100 Subject: RFR: Report correct total garbage data In-Reply-To: References: Message-ID: <3ebbf13d-b410-2d9e-6af8-5450a448f268@redhat.com> Am 24.03.2017 um 21:01 schrieb Aleksey Shipilev: > gc+ergo reports weird data: > > [21.336s][info][gc,ergo] GC(3) Total Garbage: 347M > [21.336s][info][gc,ergo] GC(3) Immediate Garbage: 216M, 27 regions > [21.336s][info][gc,ergo] GC(3) Garbage to be collected: 8072M (2323% of total), > 1062 regions > [21.336s][info][gc,ergo] GC(3) Live objects to be evacuated: 423M > > "total garbage" is wrong, because it is polled after cset is constructed. Which > excludes all regions from the cset in total garbage calculation. Trivial fix: > > http://cr.openjdk.java.net/~shade/shenandoah/policy-report-correct-garbage/webrev.01/ > > Thanks, > -Aleksey > Ok From ashipile at redhat.com Fri Mar 24 20:40:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 24 Mar 2017 20:40:03 +0000 Subject: hg: shenandoah/jdk9/hotspot: Report correct total garbage data. Message-ID: <201703242040.v2OKe3bH000644@aojmv0008.oracle.com> Changeset: 398c9ebc72e8 Author: shade Date: 2017-03-24 21:39 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/398c9ebc72e8 Report correct total garbage data. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From shade at redhat.com Mon Mar 27 17:31:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Mar 2017 19:31:42 +0200 Subject: RFR: 9+8u: Use uintptr_t in assembler.cpp In-Reply-To: <9313f828-21ce-21f9-9a1d-4b06bedae278@redhat.com> References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> <9313f828-21ce-21f9-9a1d-4b06bedae278@redhat.com> Message-ID: <9fcf1ba4-4bd3-571e-6a2c-3c0fd02b25eb@redhat.com> On 03/22/2017 01:43 PM, Andrew Haley wrote: > On 22/03/17 11:54, Aleksey Shipilev wrote: >> #elif defined(_LP64) >> +#ifdef _WINDOWS >> + const unsigned long long address_bits = 0xffffffffffffffffull; >> +#else >> const unsigned long address_bits = 0xfffffffffffffffful; >> +#endif // _WINDOWS >> #else > > I'd use uintptr_t address_bits = ~(unitptr_t)0; Right-o, this is much cleaner: http://cr.openjdk.java.net/~shade/shenandoah/assembler-uintptr/webrev.01/ Checked this still works with x86_64 {Linux, Windows} x {9, 8u}. Thanks, -Aleksey From shade at redhat.com Mon Mar 27 17:41:21 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Mar 2017 19:41:21 +0200 Subject: RFR: 9+8u: Use uintptr_t in assembler.cpp In-Reply-To: <9fcf1ba4-4bd3-571e-6a2c-3c0fd02b25eb@redhat.com> References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> <9313f828-21ce-21f9-9a1d-4b06bedae278@redhat.com> <9fcf1ba4-4bd3-571e-6a2c-3c0fd02b25eb@redhat.com> Message-ID: On 03/27/2017 07:31 PM, Aleksey Shipilev wrote: > On 03/22/2017 01:43 PM, Andrew Haley wrote: >> On 22/03/17 11:54, Aleksey Shipilev wrote: >>> #elif defined(_LP64) >>> +#ifdef _WINDOWS >>> + const unsigned long long address_bits = 0xffffffffffffffffull; >>> +#else >>> const unsigned long address_bits = 0xfffffffffffffffful; >>> +#endif // _WINDOWS >>> #else >> >> I'd use uintptr_t address_bits = ~(unitptr_t)0; > > Right-o, this is much cleaner: > http://cr.openjdk.java.net/~shade/shenandoah/assembler-uintptr/webrev.01/ > > Checked this still works with x86_64 {Linux, Windows} x {9, 8u}. Actually, let's reconsider this block now, there is no point to bitwise-and intptr_t like that: http://cr.openjdk.java.net/~shade/shenandoah/assembler-uintptr/webrev.02/ Thanks, -Aleksey From rkennke at redhat.com Tue Mar 28 10:35:17 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Mar 2017 12:35:17 +0200 Subject: RFR: 9+8u: Use uintptr_t in assembler.cpp In-Reply-To: References: <928b100b-9de2-d04e-16c5-25d3e8904b96@redhat.com> <9313f828-21ce-21f9-9a1d-4b06bedae278@redhat.com> <9fcf1ba4-4bd3-571e-6a2c-3c0fd02b25eb@redhat.com> Message-ID: <69c59141-5b66-5bcd-e0a6-ae7d83950236@redhat.com> Am 27.03.2017 um 19:41 schrieb Aleksey Shipilev: > On 03/27/2017 07:31 PM, Aleksey Shipilev wrote: >> On 03/22/2017 01:43 PM, Andrew Haley wrote: >>> On 22/03/17 11:54, Aleksey Shipilev wrote: >>>> #elif defined(_LP64) >>>> +#ifdef _WINDOWS >>>> + const unsigned long long address_bits = 0xffffffffffffffffull; >>>> +#else >>>> const unsigned long address_bits = 0xfffffffffffffffful; >>>> +#endif // _WINDOWS >>>> #else >>> I'd use uintptr_t address_bits = ~(unitptr_t)0; >> Right-o, this is much cleaner: >> http://cr.openjdk.java.net/~shade/shenandoah/assembler-uintptr/webrev.01/ >> >> Checked this still works with x86_64 {Linux, Windows} x {9, 8u}. > Actually, let's reconsider this block now, there is no point to bitwise-and > intptr_t like that: > http://cr.openjdk.java.net/~shade/shenandoah/assembler-uintptr/webrev.02/ > > Thanks, > -Aleksey > > Looks good to me. Roman From ashipile at redhat.com Tue Mar 28 10:46:17 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 28 Mar 2017 10:46:17 +0000 Subject: hg: shenandoah/jdk9/hotspot: Use uintptr_t in assembler.cpp. Message-ID: <201703281046.v2SAkHAc005426@aojmv0008.oracle.com> Changeset: 01d25ed09166 Author: shade Date: 2017-03-28 12:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/01d25ed09166 Use uintptr_t in assembler.cpp. ! src/share/vm/asm/assembler.cpp From ashipile at redhat.com Tue Mar 28 10:46:43 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 28 Mar 2017 10:46:43 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Use uintptr_t in assembler.cpp. Message-ID: <201703281046.v2SAkhcR005865@aojmv0008.oracle.com> Changeset: b733ce321ce9 Author: shade Date: 2017-03-28 12:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/b733ce321ce9 Use uintptr_t in assembler.cpp. ! src/share/vm/asm/assembler.cpp From rkennke at redhat.com Tue Mar 28 14:57:55 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Mar 2017 16:57:55 +0200 Subject: RFR: Early update references phase Message-ID: <0f573108-755d-874d-0421-658556cbf7ec@redhat.com> This implements an early reference updating phase after evacuation. It linearily scans the heap and updates all from-space reference to to-space references. It is ultimately controlled by the collector policy, which now uses the ShenandoahUpdateRefsEarly flag. The updating references phase consists of 3 sub-phases: 1. STW pre-update-refs: here we turn off evac, turn on update-refs, make heap parsable (main reason to have a pause here!), set the iteration-top-limits for later concurrent region scan. 2. Concurrent update-heap-refs: here we concurrently update references. Each GC worker claims one region at a time, and uses a (modified) marked_object_iterate() to update all refs. 3. STW post-update-refs: turn off update-refs, update all roots, reclaim all cset regions I currently see no way to avoid the additional pauses. I tested it using SPECjvm using fastdebug and release, found no more issues. Cancellation is not yet implemented, but should be easy to do (in cases of cancelled update-refs, we must not reclaim the regions and need to keep need_update_refs() to true, so that next conc-mark can pick up where we left. However, the devil is in the details: we might not only want to cancel due to OOM, but also on request of the heuristics that wants to start another conc-mark. In this case there would be no point to finish update-refs, when conc-mark can update the refs just as well. That's why I left this part out for the first prototype. http://cr.openjdk.java.net/~rkennke/update-refs/webrev.00/ Roman From rkennke at redhat.com Tue Mar 28 15:04:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Mar 2017 17:04:21 +0200 Subject: RFR: Early update references phase In-Reply-To: <0f573108-755d-874d-0421-658556cbf7ec@redhat.com> References: <0f573108-755d-874d-0421-658556cbf7ec@redhat.com> Message-ID: <8a630315-fa58-abaf-e9aa-a8232726703c@redhat.com> I should probably add that the main motivation for this is partial-GC: when we want to combine partial (minor) GCs with concurrent (intermediate) GCs, we need to fix all refs after concurrent GCs to avoid throwing off the matrix and partial GC (which can't currently deal with forwarded objects, and I can't see an easy way to do that). Notice that the matrix part isn't done yet... the update-refs phase could and should completely rebuild the matrix, and we wouldn't have to build the matrix during marking+evac. Roman > This implements an early reference updating phase after evacuation. It > linearily scans the heap and updates all from-space reference to > to-space references. It is ultimately controlled by the collector > policy, which now uses the ShenandoahUpdateRefsEarly flag. > > The updating references phase consists of 3 sub-phases: > > 1. STW pre-update-refs: here we turn off evac, turn on update-refs, make > heap parsable (main reason to have a pause here!), set the > iteration-top-limits for later concurrent region scan. > > 2. Concurrent update-heap-refs: here we concurrently update references. > Each GC worker claims one region at a time, and uses a (modified) > marked_object_iterate() to update all refs. > > 3. STW post-update-refs: turn off update-refs, update all roots, reclaim > all cset regions > > I currently see no way to avoid the additional pauses. > > I tested it using SPECjvm using fastdebug and release, found no more issues. > > Cancellation is not yet implemented, but should be easy to do (in cases > of cancelled update-refs, we must not reclaim the regions and need to > keep need_update_refs() to true, so that next conc-mark can pick up > where we left. However, the devil is in the details: we might not only > want to cancel due to OOM, but also on request of the heuristics that > wants to start another conc-mark. In this case there would be no point > to finish update-refs, when conc-mark can update the refs just as well. > That's why I left this part out for the first prototype. > > http://cr.openjdk.java.net/~rkennke/update-refs/webrev.00/ > > > Roman > > > From shade at redhat.com Tue Mar 28 15:20:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Mar 2017 17:20:05 +0200 Subject: RFR: Early update references phase In-Reply-To: <0f573108-755d-874d-0421-658556cbf7ec@redhat.com> References: <0f573108-755d-874d-0421-658556cbf7ec@redhat.com> Message-ID: <28667251-557e-c037-8206-5642eb38911b@redhat.com> On 03/28/2017 04:57 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/update-refs/webrev.00/ Looks good. There is no need to update references during concmark if heuristics called to do this early, right? Cheers, -Aleksey From rkennke at redhat.com Tue Mar 28 15:21:45 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Mar 2017 17:21:45 +0200 Subject: RFR: Early update references phase In-Reply-To: <28667251-557e-c037-8206-5642eb38911b@redhat.com> References: <0f573108-755d-874d-0421-658556cbf7ec@redhat.com> <28667251-557e-c037-8206-5642eb38911b@redhat.com> Message-ID: <7fb3a90f-7ba5-39c3-fa90-0c103c0e4d6c@redhat.com> Am 28.03.2017 um 17:20 schrieb Aleksey Shipilev: > On 03/28/2017 04:57 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/update-refs/webrev.00/ > Looks good. > > There is no need to update references during concmark if heuristics called to do > this early, right? Nope. And it is implemented like this I think. Roman From roman at kennke.org Tue Mar 28 15:23:04 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 28 Mar 2017 15:23:04 +0000 Subject: hg: shenandoah/jdk9/hotspot: Implement early update references phase. Message-ID: <201703281523.v2SFN4a9006053@aojmv0008.oracle.com> Changeset: 205245754a53 Author: rkennke Date: 2017-03-28 17:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/205245754a53 Implement early update references phase. ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.hpp ! src/share/vm/runtime/vm_operations.hpp From shade at redhat.com Tue Mar 28 18:53:10 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Mar 2017 20:53:10 +0200 Subject: RFR: Optimize ShMatrix::clear_(in|out)bound Message-ID: <795b88f7-db99-efd9-b149-7035597c0cef@redhat.com> We know from sore experience that these methods are slow, and they are called in our critical paused phases in experimental partial and update-ref code. It makes sense to optimize it: http://cr.openjdk.java.net/~shade/shenandoah/matrix-clear-inoutbound/webrev.01/ Improves update-refs: [56.765s][info][gc,stats] Pause Post Update References = 0.11 s (a = 18277 us) (n = 6) (lvls, us = 16602, 16602, 16992, 19141, 20516) [56.784s][info][gc,stats] Pause Post Update References = 0.04 s (a = 6097 us) (n = 6) (lvls, us = 5488, 5488, 5723, 6309, 6958) Improves partial: [56.887s][info][gc,stats] Partial GC = 2.75 s (a = 58532 us) (n = 47) (lvls, us = 48242, 49219, 50195, 58594, 154002) [56.911s][info][gc,stats] Partial GC = 2.63 s (a = 55895 us) (n = 47) (lvls, us = 45117, 46484, 47656, 58742, 149117) -Aleksey From roman at kennke.org Tue Mar 28 18:59:28 2017 From: roman at kennke.org (Roman Kennke) Date: Tue, 28 Mar 2017 20:59:28 +0200 Subject: RFR: Optimize ShMatrix::clear_(in|out)bound In-Reply-To: <795b88f7-db99-efd9-b149-7035597c0cef@redhat.com> References: <795b88f7-db99-efd9-b149-7035597c0cef@redhat.com> Message-ID: Ok Am 28. M?rz 2017 20:53:10 MESZ schrieb Aleksey Shipilev : >We know from sore experience that these methods are slow, and they are >called in >our critical paused phases in experimental partial and update-ref code. >It makes >sense to optimize it: >http://cr.openjdk.java.net/~shade/shenandoah/matrix-clear-inoutbound/webrev.01/ > >Improves update-refs: > >[56.765s][info][gc,stats] Pause Post Update References = > 0.11 s (a = 18277 us) (n = 6) > (lvls, us = 16602, 16602, 16992, 19141, 20516) > >[56.784s][info][gc,stats] Pause Post Update References = > 0.04 s (a = 6097 us) (n = 6) > (lvls, us = 5488, 5488, 5723, 6309, 6958) > >Improves partial: > >[56.887s][info][gc,stats] Partial GC = > 2.75 s (a = 58532 us) (n = 47) > (lvls, us = 48242, 49219, 50195, 58594, 154002) > >[56.911s][info][gc,stats] Partial GC = > 2.63 s (a = 55895 us) (n = 47) > (lvls, us = 45117, 46484, 47656, 58742, 149117) > > >-Aleksey -- Sent from my FairPhone From zgu at redhat.com Tue Mar 28 19:07:04 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Mar 2017 15:07:04 -0400 Subject: RFR: Optimize ShMatrix::clear_(in|out)bound In-Reply-To: <795b88f7-db99-efd9-b149-7035597c0cef@redhat.com> References: <795b88f7-db99-efd9-b149-7035597c0cef@redhat.com> Message-ID: <60430d96-50e2-5190-5443-2c55747c3d87@redhat.com> Good to me. -Zhengyu On 03/28/2017 02:53 PM, Aleksey Shipilev wrote: > We know from sore experience that these methods are slow, and they are called in > our critical paused phases in experimental partial and update-ref code. It makes > sense to optimize it: > http://cr.openjdk.java.net/~shade/shenandoah/matrix-clear-inoutbound/webrev.01/ > > Improves update-refs: > > [56.765s][info][gc,stats] Pause Post Update References = > 0.11 s (a = 18277 us) (n = 6) > (lvls, us = 16602, 16602, 16992, 19141, 20516) > > [56.784s][info][gc,stats] Pause Post Update References = > 0.04 s (a = 6097 us) (n = 6) > (lvls, us = 5488, 5488, 5723, 6309, 6958) > > Improves partial: > > [56.887s][info][gc,stats] Partial GC = > 2.75 s (a = 58532 us) (n = 47) > (lvls, us = 48242, 49219, 50195, 58594, 154002) > > [56.911s][info][gc,stats] Partial GC = > 2.63 s (a = 55895 us) (n = 47) > (lvls, us = 45117, 46484, 47656, 58742, 149117) > > > -Aleksey > > From ashipile at redhat.com Tue Mar 28 20:01:51 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 28 Mar 2017 20:01:51 +0000 Subject: hg: shenandoah/jdk9/hotspot: Optimize ShMatrix::clear_(in|out)bound. Message-ID: <201703282001.v2SK1pjM019831@aojmv0008.oracle.com> Changeset: def67bf9f56d Author: shade Date: 2017-03-28 21:02 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/def67bf9f56d Optimize ShMatrix::clear_(in|out)bound. ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.hpp From rkennke at redhat.com Tue Mar 28 20:46:18 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Mar 2017 22:46:18 +0200 Subject: RFR: Add missing null check in assert Message-ID: <3bd63c4b-a661-d98b-482d-684e6a065d6f@redhat.com> the GCBasher test started to fail with my last update-references change. It's caused by an attempt to resolve the brooks ptr of an object that may become NULL in an assert. I added a null-check there to avoid the problem. http://cr.openjdk.java.net/~rkennke/missingnullcheck/webrev.00/ Roman From shade at redhat.com Wed Mar 29 07:43:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 29 Mar 2017 09:43:25 +0200 Subject: RFR: Add missing null check in assert In-Reply-To: <3bd63c4b-a661-d98b-482d-684e6a065d6f@redhat.com> References: <3bd63c4b-a661-d98b-482d-684e6a065d6f@redhat.com> Message-ID: <1f401f60-a937-2702-860c-f3e52f10ce2a@redhat.com> On 03/28/2017 10:46 PM, Roman Kennke wrote: > the GCBasher test started to fail with my last update-references change. > It's caused by an attempt to resolve the brooks ptr of an object that > may become NULL in an assert. I added a null-check there to avoid the > problem. > > http://cr.openjdk.java.net/~rkennke/missingnullcheck/webrev.00/ OK. -Aleksey From roman at kennke.org Wed Mar 29 08:29:46 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 29 Mar 2017 08:29:46 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add missing null check in assert. Message-ID: <201703290829.v2T8Tkpp011379@aojmv0008.oracle.com> Changeset: 38944b2fb3c9 Author: rkennke Date: 2017-03-29 10:28 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/38944b2fb3c9 Add missing null check in assert. ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp From rkennke at redhat.com Wed Mar 29 15:02:55 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 29 Mar 2017 17:02:55 +0200 Subject: RFR: Make update-refs cancellable Message-ID: <9c7cecd0-9a72-6d64-c406-0f0812837a21@redhat.com> This makes update-refs respect cancellation due to OOM, and short-circuit it to arrive at full-gc faster. It does *not* implement short-circuiting for the case where heuristics would want to start a new GC cycle. This is significantly more difficult. http://cr.openjdk.java.net/~rkennke/cancel-update-refs/webrev.00/ Roman From zgu at redhat.com Wed Mar 29 15:44:06 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 29 Mar 2017 11:44:06 -0400 Subject: RFR: Make update-refs cancellable In-Reply-To: <9c7cecd0-9a72-6d64-c406-0f0812837a21@redhat.com> References: <9c7cecd0-9a72-6d64-c406-0f0812837a21@redhat.com> Message-ID: <86f1380e-ade6-6880-ba3e-0a03879d7c5f@redhat.com> Looks good. -Zhengyu On 03/29/2017 11:02 AM, Roman Kennke wrote: > This makes update-refs respect cancellation due to OOM, and > short-circuit it to arrive at full-gc faster. > > It does *not* implement short-circuiting for the case where heuristics > would want to start a new GC cycle. This is significantly more difficult. > > http://cr.openjdk.java.net/~rkennke/cancel-update-refs/webrev.00/ > > > Roman > > From roman at kennke.org Wed Mar 29 16:10:23 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 29 Mar 2017 16:10:23 +0000 Subject: hg: shenandoah/jdk9/hotspot: Make update-refs cancellable. Message-ID: <201703291610.v2TGANmv019626@aojmv0008.oracle.com> Changeset: e78d26910a81 Author: rkennke Date: 2017-03-29 18:07 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e78d26910a81 Make update-refs cancellable. ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp From rkennke at redhat.com Thu Mar 30 11:48:49 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 13:48:49 +0200 Subject: RFR: Improve inlining of the update-refs closure. Implement update-refs verification. Message-ID: <2c00eee7-393f-4f12-5732-0c48a52004f2@redhat.com> This makes the update-refs closure inline better. It's done by adding a templated marked_object_oop_iterate() method that uses a templated object->oop closure and call marked_object_iterate() with that. The effect is that the call to obj->oop_iterate() can use a non-virtual inlined call to the actual OopClosure. I've also added a little verification routine that checks that no marked object points to any to-space object after updating references. http://cr.openjdk.java.net/~rkennke/update-refs-inlining/webrev.01/ (Notice the marked_object_oop_iterate() will also come handy for partial collections: currently we're iterating all objects there, but only need to actually see marked objects. Plus the inlining of course.) Tested using specjvm and hotspot_gc_shenandoah. Roman From rkennke at redhat.com Thu Mar 30 12:48:20 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 14:48:20 +0200 Subject: RFR: Improve inlining of the update-refs closure. Implement update-refs verification. In-Reply-To: <2c00eee7-393f-4f12-5732-0c48a52004f2@redhat.com> References: <2c00eee7-393f-4f12-5732-0c48a52004f2@redhat.com> Message-ID: <9038b6eb-9810-decf-f366-488b49271970@redhat.com> Am 30.03.2017 um 13:48 schrieb Roman Kennke: > This makes the update-refs closure inline better. > > It's done by adding a templated marked_object_oop_iterate() method that > uses a templated object->oop closure and call marked_object_iterate() > with that. The effect is that the call to obj->oop_iterate() can use a > non-virtual inlined call to the actual OopClosure. > > I've also added a little verification routine that checks that no marked > object points to any to-space object after updating references. > > http://cr.openjdk.java.net/~rkennke/update-refs-inlining/webrev.01/ > > > (Notice the marked_object_oop_iterate() will also come handy for partial > collections: currently we're iterating all objects there, but only need > to actually see marked objects. Plus the inlining of course.) > > Tested using specjvm and hotspot_gc_shenandoah. > > Roman > > I should probably also note a slight performance improvement when running specjvm compiler: baseline: [189,449s][info][gc,stats] Concurrent Update References = 17,74 s (a = 286206 us) (n = 62) (lvls, us = 96484, 228516, 265625, 345703, 425766) patched: [194,266s][info][gc,stats] Concurrent Update References = 15,04 s (a = 246623 us) (n = 61) (lvls, us = 60352, 201172, 251953, 296875, 434468) Roman From shade at redhat.com Thu Mar 30 13:06:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 15:06:42 +0200 Subject: RFR: Improve inlining of the update-refs closure. Implement update-refs verification. In-Reply-To: <2c00eee7-393f-4f12-5732-0c48a52004f2@redhat.com> References: <2c00eee7-393f-4f12-5732-0c48a52004f2@redhat.com> Message-ID: On 03/30/2017 01:48 PM, Roman Kennke wrote: > This makes the update-refs closure inline better. > > It's done by adding a templated marked_object_oop_iterate() method that > uses a templated object->oop closure and call marked_object_iterate() > with that. The effect is that the call to obj->oop_iterate() can use a > non-virtual inlined call to the actual OopClosure. > > I've also added a little verification routine that checks that no marked > object points to any to-space object after updating references. > > http://cr.openjdk.java.net/~rkennke/update-refs-inlining/webrev.01/ Looks fine. -Aleksey From roman at kennke.org Thu Mar 30 13:14:59 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 30 Mar 2017 13:14:59 +0000 Subject: hg: shenandoah/jdk9/hotspot: Improve inlining of the update-refs closure. Implement update-refs verification. Message-ID: <201703301315.v2UDF0T2022062@aojmv0008.oracle.com> Changeset: eb6ebd9816cf Author: rkennke Date: 2017-03-30 15:13 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/eb6ebd9816cf Improve inlining of the update-refs closure. Implement update-refs verification. ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc/shenandoah/shenandoah_specialized_oop_closures.hpp From rkennke at redhat.com Thu Mar 30 15:58:45 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 17:58:45 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs Message-ID: This brings together partial GCs with Shenandoah's ordinary concurrent GC. The ShenandoahConcurrentThread kicks off a normal concurrent GC cycle just like the adaptive heuristics (the superclass of partial heuristics), i.e. when heap usage reaches a certain threshold. It forces an update-refs phase after the concurrent cycle to prepare for the next partial cycle. The update-refs phase completely rebuilds the matrix. This means we don't have to build it during marking. That's why I throw away all the additional marking closures. http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.00/ Tested using specjvm and hotspot_gc_shenandoah. Roman From rkennke at redhat.com Thu Mar 30 17:27:44 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 19:27:44 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs In-Reply-To: References: Message-ID: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> Am 30.03.2017 um 17:58 schrieb Roman Kennke: > This brings together partial GCs with Shenandoah's ordinary concurrent GC. > > The ShenandoahConcurrentThread kicks off a normal concurrent GC cycle > just like the adaptive heuristics (the superclass of partial > heuristics), i.e. when heap usage reaches a certain threshold. It forces > an update-refs phase after the concurrent cycle to prepare for the next > partial cycle. > > The update-refs phase completely rebuilds the matrix. This means we > don't have to build it during marking. That's why I throw away all the > additional marking closures. > > http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.00/ > > > Tested using specjvm and hotspot_gc_shenandoah. > > Roman > Ok, the interleave part is misleading. It does not actually interleave concurrent with partial GCs. It either does one or the other in each GC phase. Also, we might need the matrix that is built by concurrent marking, to select which regions need updating during update-refs. Better to leave that code in. Which makes the patch fairly concise: http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.01 Ok now? Roman From shade at redhat.com Thu Mar 30 18:03:21 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 20:03:21 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs In-Reply-To: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> References: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> Message-ID: <7f1947b7-1388-ba1c-1a21-9e96f1bd934d@redhat.com> On 03/30/2017 07:27 PM, Roman Kennke wrote: > Ok, the interleave part is misleading. It does not actually interleave > concurrent with partial GCs. It either does one or the other in each GC > phase. > > Also, we might need the matrix that is built by concurrent marking, to > select which regions need updating during update-refs. Better to leave > that code in. Which makes the patch fairly concise: > > http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.01 OK. -Aleksey From shade at redhat.com Thu Mar 30 19:22:15 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 21:22:15 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs In-Reply-To: <7f1947b7-1388-ba1c-1a21-9e96f1bd934d@redhat.com> References: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> <7f1947b7-1388-ba1c-1a21-9e96f1bd934d@redhat.com> Message-ID: On 03/30/2017 08:03 PM, Aleksey Shipilev wrote: > On 03/30/2017 07:27 PM, Roman Kennke wrote: >> Ok, the interleave part is misleading. It does not actually interleave >> concurrent with partial GCs. It either does one or the other in each GC >> phase. >> >> Also, we might need the matrix that is built by concurrent marking, to >> select which regions need updating during update-refs. Better to leave >> that code in. Which makes the patch fairly concise: >> >> http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.01 > > OK. This SEGVs for me. In my workload, the very first cycle is partial, but marking bitmap is not available yet. This band-aids the issue, but I am not sure it should be fixed like that: http://cr.openjdk.java.net/~shade/shenandoah/bandaid-first-partial.patch -Aleksey From shade at redhat.com Thu Mar 30 19:23:40 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 21:23:40 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs In-Reply-To: References: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> <7f1947b7-1388-ba1c-1a21-9e96f1bd934d@redhat.com> Message-ID: <572442f5-275d-8550-e1e0-ab7df2b989b1@redhat.com> On 03/30/2017 09:22 PM, Aleksey Shipilev wrote: > On 03/30/2017 08:03 PM, Aleksey Shipilev wrote: >> On 03/30/2017 07:27 PM, Roman Kennke wrote: >>> Ok, the interleave part is misleading. It does not actually interleave >>> concurrent with partial GCs. It either does one or the other in each GC >>> phase. >>> >>> Also, we might need the matrix that is built by concurrent marking, to >>> select which regions need updating during update-refs. Better to leave >>> that code in. Which makes the patch fairly concise: >>> >>> http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.01 >> >> OK. > > This SEGVs for me. In my workload, the very first cycle is partial, but marking > bitmap is not available yet. This band-aids the issue, but I am not sure it > should be fixed like that: > http://cr.openjdk.java.net/~shade/shenandoah/bandaid-first-partial.patch Ah, should also handle partial after full GC, which fails the same. -Aleksey From rkennke at redhat.com Thu Mar 30 19:44:38 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 21:44:38 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs In-Reply-To: References: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> <7f1947b7-1388-ba1c-1a21-9e96f1bd934d@redhat.com> Message-ID: <7727f74f-1b8d-ebe5-1af6-54803c98434a@redhat.com> Am 30.03.2017 um 21:22 schrieb Aleksey Shipilev: > On 03/30/2017 08:03 PM, Aleksey Shipilev wrote: >> On 03/30/2017 07:27 PM, Roman Kennke wrote: >>> Ok, the interleave part is misleading. It does not actually interleave >>> concurrent with partial GCs. It either does one or the other in each GC >>> phase. >>> >>> Also, we might need the matrix that is built by concurrent marking, to >>> select which regions need updating during update-refs. Better to leave >>> that code in. Which makes the patch fairly concise: >>> >>> http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.01 >> OK. > This SEGVs for me. In my workload, the very first cycle is partial, but marking > bitmap is not available yet. This band-aids the issue, but I am not sure it > should be fixed like that: > http://cr.openjdk.java.net/~shade/shenandoah/bandaid-first-partial.patch No it shouldn't :-) When there is no marking bitmap, it should happily fall back to size-based iteration. The issue here is that we're encountering a humongous continuation, and marked_object_iterate() cannot handle it. This modification puts an assert in marked_object_iterate() and skips humongous continuations. (They will be processed by the oop_iterate() call in the humongous start anyway). http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.02/ Roman From shade at redhat.com Thu Mar 30 19:45:37 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 21:45:37 +0200 Subject: RFR: Interleave partial GCs with concurrent GCs In-Reply-To: <7727f74f-1b8d-ebe5-1af6-54803c98434a@redhat.com> References: <2f86afa5-ad07-de8a-d495-527cf3ef5ab1@redhat.com> <7f1947b7-1388-ba1c-1a21-9e96f1bd934d@redhat.com> <7727f74f-1b8d-ebe5-1af6-54803c98434a@redhat.com> Message-ID: On 03/30/2017 09:44 PM, Roman Kennke wrote: > Am 30.03.2017 um 21:22 schrieb Aleksey Shipilev: >> On 03/30/2017 08:03 PM, Aleksey Shipilev wrote: >>> On 03/30/2017 07:27 PM, Roman Kennke wrote: >>>> Ok, the interleave part is misleading. It does not actually interleave >>>> concurrent with partial GCs. It either does one or the other in each GC >>>> phase. >>>> >>>> Also, we might need the matrix that is built by concurrent marking, to >>>> select which regions need updating during update-refs. Better to leave >>>> that code in. Which makes the patch fairly concise: >>>> >>>> http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.01 >>> OK. >> This SEGVs for me. In my workload, the very first cycle is partial, but marking >> bitmap is not available yet. This band-aids the issue, but I am not sure it >> should be fixed like that: >> http://cr.openjdk.java.net/~shade/shenandoah/bandaid-first-partial.patch > No it shouldn't :-) > When there is no marking bitmap, it should happily fall back to > size-based iteration. > > The issue here is that we're encountering a humongous continuation, and > marked_object_iterate() cannot handle it. > > This modification puts an assert in marked_object_iterate() and skips > humongous continuations. (They will be processed by the oop_iterate() > call in the humongous start anyway). > > http://cr.openjdk.java.net/~rkennke/partial-conc-gc/webrev.02/ OK! -Aleksey From roman at kennke.org Thu Mar 30 19:46:57 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 30 Mar 2017 19:46:57 +0000 Subject: hg: shenandoah/jdk9/hotspot: Interleave partial GCs with concurrent GCs. Message-ID: <201703301946.v2UJkv1r019975@aojmv0008.oracle.com> Changeset: 85ad2bfde517 Author: rkennke Date: 2017-03-30 21:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/85ad2bfde517 Interleave partial GCs with concurrent GCs. ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From rkennke at redhat.com Thu Mar 30 19:49:51 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 21:49:51 +0200 Subject: RFR: Improve inlining of the root scanning closure in partial GC Message-ID: <6250177f-c692-4713-e7ee-8f643e23f2a5@redhat.com> As $SUBJECT says. It generates inlined oop iterators for the PartialEvacuateUpdateHeapClosure, and thus speeds up root region scanning. http://cr.openjdk.java.net/~rkennke/inline-partial-closures/webrev.00/ Roman From shade at redhat.com Thu Mar 30 20:05:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 22:05:34 +0200 Subject: RFR: Improve inlining of the root scanning closure in partial GC In-Reply-To: <6250177f-c692-4713-e7ee-8f643e23f2a5@redhat.com> References: <6250177f-c692-4713-e7ee-8f643e23f2a5@redhat.com> Message-ID: <3b224991-e33d-720b-5fe8-c7995bc4ee86@redhat.com> On 03/30/2017 09:49 PM, Roman Kennke wrote: > As $SUBJECT says. It generates inlined oop iterators for the > PartialEvacuateUpdateHeapClosure, and thus speeds up root region scanning. > > http://cr.openjdk.java.net/~rkennke/inline-partial-closures/webrev.00/ Where did the ShenandoahPartialGC::process_oop implementation go? -Aleksey From rkennke at redhat.com Thu Mar 30 20:09:04 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Mar 2017 22:09:04 +0200 Subject: RFR: Improve inlining of the root scanning closure in partial GC In-Reply-To: <3b224991-e33d-720b-5fe8-c7995bc4ee86@redhat.com> References: <6250177f-c692-4713-e7ee-8f643e23f2a5@redhat.com> <3b224991-e33d-720b-5fe8-c7995bc4ee86@redhat.com> Message-ID: Am 30.03.2017 um 22:05 schrieb Aleksey Shipilev: > On 03/30/2017 09:49 PM, Roman Kennke wrote: >> As $SUBJECT says. It generates inlined oop iterators for the >> PartialEvacuateUpdateHeapClosure, and thus speeds up root region scanning. >> >> http://cr.openjdk.java.net/~rkennke/inline-partial-closures/webrev.00/ > Where did the ShenandoahPartialGC::process_oop implementation go? Oops. Forgot to add new file. http://cr.openjdk.java.net/~rkennke/inline-partial-closures/webrev.01/ Roman From shade at redhat.com Thu Mar 30 20:10:58 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Mar 2017 22:10:58 +0200 Subject: RFR: Improve inlining of the root scanning closure in partial GC In-Reply-To: References: <6250177f-c692-4713-e7ee-8f643e23f2a5@redhat.com> <3b224991-e33d-720b-5fe8-c7995bc4ee86@redhat.com> Message-ID: <3e332354-931f-afff-ac8e-f62986d69b09@redhat.com> On 03/30/2017 10:09 PM, Roman Kennke wrote: > Am 30.03.2017 um 22:05 schrieb Aleksey Shipilev: >> On 03/30/2017 09:49 PM, Roman Kennke wrote: >>> As $SUBJECT says. It generates inlined oop iterators for the >>> PartialEvacuateUpdateHeapClosure, and thus speeds up root region scanning. >>> >>> http://cr.openjdk.java.net/~rkennke/inline-partial-closures/webrev.00/ >> Where did the ShenandoahPartialGC::process_oop implementation go? > Oops. Forgot to add new file. > > http://cr.openjdk.java.net/~rkennke/inline-partial-closures/webrev.01/ OK! -Aleksey From roman at kennke.org Thu Mar 30 20:31:37 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 30 Mar 2017 20:31:37 +0000 Subject: hg: shenandoah/jdk9/hotspot: Improve inlining of the root scanning closure in partial GC. Message-ID: <201703302031.v2UKVcs9000668@aojmv0008.oracle.com> Changeset: 671a6b8102d3 Author: rkennke Date: 2017-03-30 22:07 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/671a6b8102d3 Improve inlining of the root scanning closure in partial GC. ! src/share/vm/gc/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp + src/share/vm/gc/shenandoah/shenandoahPartialGC.inline.hpp ! src/share/vm/gc/shenandoah/shenandoah_specialized_oop_closures.hpp From rkennke at redhat.com Fri Mar 31 10:50:16 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 31 Mar 2017 12:50:16 +0200 Subject: RFR: Correctly iterate references in humongous regions Message-ID: The new marked_object_oop_iterate() does not correctly handle humongous regions: for the humongous start region, it would iterate over all references in the humongous array, even those in humongous continuations, attempting to iterate humongous continuations would crash. This patch makes oop* iteration using marked_object_oop_iterate() consistent with ShenandoahHeapRegion::oop_iterate(): it iterates only oop* that are within the region, even for humongous start and continuation regions. This is important not only for consistency (with SHR::oop_iterate()) and efficiency (allows to distribute iteration over GC threads), but also for correctness: partial GC/connection matrix tracks precisely which regions point to which, and only attempts to scan root regions, even if they are interior in humongous arrays. Tested by specjvm and hotspot_gc_shenandoah. http://cr.openjdk.java.net/~rkennke/oop-iterate-humongous/webrev.00/ Roman From shade at redhat.com Fri Mar 31 12:51:46 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 Mar 2017 14:51:46 +0200 Subject: RFR: Correctly iterate references in humongous regions In-Reply-To: References: Message-ID: <863be35c-0866-c4a4-8a78-f353cc478fc3@redhat.com> On 03/31/2017 12:50 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/oop-iterate-humongous/webrev.00/ This makes me a little itchy: 547 while (! region->is_humongous_start()) { 548 region = _ordered_regions->get(region->region_number() - 1); 549 } Rewind could use a simple local var? Otherwise good. -Aleksey From rkennke at redhat.com Fri Mar 31 13:40:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 31 Mar 2017 15:40:07 +0200 Subject: RFR: Correctly iterate references in humongous regions In-Reply-To: <863be35c-0866-c4a4-8a78-f353cc478fc3@redhat.com> References: <863be35c-0866-c4a4-8a78-f353cc478fc3@redhat.com> Message-ID: Am 31.03.2017 um 14:51 schrieb Aleksey Shipilev: > On 03/31/2017 12:50 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/oop-iterate-humongous/webrev.00/ > This makes me a little itchy: > > 547 while (! region->is_humongous_start()) { > 548 region = _ordered_regions->get(region->region_number() - 1); > 549 } > > Rewind could use a simple local var? Yeap. I also noticed that I haven't done the version with limit yet. I made up my mind about this, and realized that we don't really want iteration up to arbitrary limits: this is meant to be used specifically with the concurrent-iteration-safe-limit, and should say so in the API. I changed those methods to include 'safe_iterate' (consistent with Space's safe_iterate() methods), and put the actual impls into private methods that take the upper limit. http://cr.openjdk.java.net/~rkennke/oop-iterate-humongous/webrev.00/ Good now? Roman From rkennke at redhat.com Fri Mar 31 14:21:43 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 31 Mar 2017 16:21:43 +0200 Subject: RFR: Disable over-strong assert Message-ID: <3b321c79-1aed-c16e-7a07-43502ef37338@redhat.com> I recently put an assert in maybe_update_heap_oop() which asserts that when a Java thread beat us with a store, that the stored value is to-space. There's a small gotcha there: if the Java thread beat us with an arraycopy, there is a small window where we can see from-space values, before the Java thread calls the post-ref-array-barrier. http://cr.openjdk.java.net/~rkennke/disable-assert/webrev.00/ Roman From zgu at redhat.com Fri Mar 31 19:33:25 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 31 Mar 2017 15:33:25 -0400 Subject: RFR: Disable over-strong assert In-Reply-To: <3b321c79-1aed-c16e-7a07-43502ef37338@redhat.com> References: <3b321c79-1aed-c16e-7a07-43502ef37338@redhat.com> Message-ID: Good to me. -Zhengyu On 03/31/2017 10:21 AM, Roman Kennke wrote: > I recently put an assert in maybe_update_heap_oop() which asserts that > when a Java thread beat us with a store, that the stored value is > to-space. There's a small gotcha there: if the Java thread beat us with > an arraycopy, there is a small window where we can see from-space > values, before the Java thread calls the post-ref-array-barrier. > > http://cr.openjdk.java.net/~rkennke/disable-assert/webrev.00/ > > > Roman > > From zgu at redhat.com Fri Mar 31 19:41:21 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 31 Mar 2017 15:41:21 -0400 Subject: RFR: Correctly iterate references in humongous regions In-Reply-To: References: <863be35c-0866-c4a4-8a78-f353cc478fc3@redhat.com> Message-ID: <54daa0ee-0908-a0a9-e537-a4892947f0cf@redhat.com> On 03/31/2017 09:40 AM, Roman Kennke wrote: > Am 31.03.2017 um 14:51 schrieb Aleksey Shipilev: >> On 03/31/2017 12:50 PM, Roman Kennke wrote: >>> http://cr.openjdk.java.net/~rkennke/oop-iterate-humongous/webrev.00/ >> This makes me a little itchy: >> >> 547 while (! region->is_humongous_start()) { >> 548 region = _ordered_regions->get(region->region_number() - 1); >> 549 } >> >> Rewind could use a simple local var? > > Yeap. > > I also noticed that I haven't done the version with limit yet. I made up > my mind about this, and realized that we don't really want iteration up > to arbitrary limits: this is meant to be used specifically with the > concurrent-iteration-safe-limit, and should say so in the API. I changed > those methods to include 'safe_iterate' (consistent with Space's > safe_iterate() methods), and put the actual impls into private methods > that take the upper limit. > > http://cr.openjdk.java.net/~rkennke/oop-iterate-humongous/webrev.00/ > > > Good now? It seems that you have yet address what Aleksey suggested. -Zhengyu > > Roman > From gnu.andrew at redhat.com Thu Mar 9 04:09:32 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 09 Mar 2017 04:09:32 -0000 Subject: [aarch64-port-dev ] RFR: GensrcMisc.gmk linker issue on windows In-Reply-To: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> References: <66947599-ec9e-eabe-18b4-37dcb5c022fd@redhat.com> Message-ID: <523417235.5848960.1489032545189.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > we're unable to build on windows due to link issue > > /out:genSocketOptionRegistry.exe > /out:ut:r:/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.exe > > r:/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.obj > > LINK : fatal error LNK1104: cannot open file > 'ut:r:/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.exe' > make[2]: *** [gensrc/GensrcMisc.gmk:75: > /cygdrive/r/buildroot/jdk/btnative/genSocketOptionRegistry/genSocketOptionRegistry.exe] > Error 2 > > > This fix the issue: > aarch64-port/jdk8u - > https://michalvala.fedorapeople.org/webrevs/gensrcmisclinker-aarch64/webrev.00/ > aarch64-port/jdk8u-shenandoah - > https://michalvala.fedorapeople.org/webrevs/gensrcmisclinker-aarch64-shenandoah/webrev.00/ > > -- > -Michal > This is a divergence from upstream jdk8u, silently introduced by: changeset: 11016:391be061dfc7 parent: 11015:7ebad38ac2b3 parent: 8810:fc4ac66aa657 user: Edward Nevill edward.nevill at linaro.org date: Mon Dec 23 13:00:14 2013 +0000 summary: Remerge to jdk8-b117 Have you tested that reverting this to the upstream jdk8u version doesn't break aarch64? I did a comparison of upstream jdk8u121-b14 with the current state of aarch64/jdk8u (attached) and all other changes do seem to be necessary for aarch64 (the test issue is a merge issue already resolved in the main jdk8u tree, but not jdk8u121-b14). -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 -------------- next part -------------- A non-text attachment was scrubbed... Name: aarch64.jdk.patch Type: text/x-patch Size: 6962 bytes Desc: not available URL: From cflood at redhat.com Wed Mar 22 17:20:27 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 22 Mar 2017 17:20:27 -0000 Subject: RFR: Turn PrintShenandoahMatrix back on. Message-ID: http://cr.openjdk.java.net/~chf/printMatrix.00/