RFR: enqueue barrier + some other things
Aleksey Shipilev
shade at redhat.com
Thu Jun 21 08:22:26 UTC 2018
On 06/21/2018 09:38 AM, Roland Westrelin wrote:
>
>> No, assuming it only moves the method bodies without any other changes.
>
> Ok. So here is rest of the change:
>
> http://cr.openjdk.java.net/~roland/shenandoah/enqueue-barrier/webrev.00/
The patch seems to pass tier3_gc_shenandoah.
*) This condition in ShenandoahWriteBarrierNode::expand looks odd:
586 if (ShenandoahBarrierSetC2::bsc2()->state()->shenandoah_barriers_count() > 0 ||
(!ShenandoahWriteBarrier && ShenandoahStoreValEnqueueBarrier)) {
The second part enables when -WB && +SVEB. When this configuration actually manifests? I think
Traversal still uses both WB and SVEB.
*) The change to barrierSetC2 should be on our list to upstream. I wonder if boolean parameter
should be at the second place:
virtual bool array_copy_requires_gc_barriers(BasicType type, bool tightly_coupled_allocation);
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list