Shenandoah WB fastpath and optimizations

[Roman Kennke]

> P.S. Looking at ShenandoahWriteBarrierNode::test_evacuation_in_progress, I see there is
> Op_MemBarAcquire node that is attached to control projection for both CmpI and Bool nodes from WB.
> Are these limiting the optimizations? Why do we need acquire there? This had originated from
> Roland's change rewrite that introduced shenandoah_pin_and_expand_barriers:
> http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/978d7601df14#l20.1137

This is the membar that we need between loading the evac_in_progress and 
the load of the brooks ptr. If we don't have it, we cannot turn off 
evac-in-progress concurrently. We don't strictly need Acquire, we 'only' 
need a LoadLoad membar, on x86 meaning that the instructions need to be 
emitted in correct order. I cannot say if this possibly prevents 
optimizations.

Roman