RFR: fix aarch64 membar elision with shenandoah

[Roman Kennke]

Am 13.07.2018 um 16:37 schrieb Aleksey Shipilev:
> On 07/13/2018 04:33 PM, Roland Westrelin wrote:
>>
>>> Oh wait, I just got this from a test:
>>>
>>> #  Internal Error
>>> (/home/rkennke/src/shenandoah-jdk/src/hotspot/cpu/aarch64/aarch64.ad:2873),
>>> pid=27969, tid=28271
>>> #  guarantee(mbar != NULL) failed: CAS not embedded in normal graph!
>>
>> With this test we're running with:
>>
>> -XX:+ShenandoahSATBBarrier -XX:+ShenandoahWriteBarrier -XX:+ShenandoahReadBarrier -XX:+ShenandoahStoreValEnqueueBarrier
>>
>> so we have a write barrier, an enqueue barrier and a satb barrier above
>> the CAS. Why does it make sense to run with options that are not usually
>> enabled together?
> 
> The test is used to verify that we do not emit barriers when particular types of barriers are
> disabled: there are asserts all over runtime, C1 and C2 code to test these. Over time, it started to
> be the test to make sure that arguments/heuristics code verifies and drops the incompatible
> combination of flags.
> 
> -Aleksey
> 
> 

Yes, but enqueue-barriers and satb-barriers are mutally exclusive. There
is no point in enabling both. In fact, we should check+verify that this
is not even attempted.

Roman