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