RFR: enqueue barrier + some other things

[Roman Kennke]

In test_evacuation_in_progress() you are not reusing the gc_state load
from the test_heap_stable() test. I tried doing this, but got a crash.
Would C2 common up the 2 loads anyway? This seems useful.

What I *really* would like to have is to avoid the whole
evac-in-progress check at all, and only emit heap-stable-test for
traversal, for both WBs and EQBs. Would that be possible? As follow-up?
I tried to hack it by short-circuiting test_evacuation_in_progress after
the null-check, but it did not work (of course. it's C2 ;-) ).

Thanks for this work!
Roman

> http://cr.openjdk.java.net/~roland/shenandoah/enqueue-barrier/webrev.00/
> 
> This implements the traversal's enqueue barrier as a standalone node
> that's expanded at the the same time the write barriers are expanded.
> 
> Also:
> 
> We used to guard a write barrier with a null check at parse time:
> 
> if (val != null) {
>   val' = wb(val);
> }
> 
> I removed the null check from parse time and it is now added at
> expansion time so the write barrier can float around during
> optimizations. I also swapped the heap stable test and the null check
> because I suppose val is often non null:
> 
> if (!heap stable) {
>   if (val != null) {
>     // rest of write barrier code
>   }
> }
> 
> I found a bug that could cause write barriers to be moved to a more
> frequent path. That's fixed.
> 
> To move write barriers around and to expand write barriers, I need to
> hack the memory graph. I had 2 ways to do that (a "simple" one for write
> barrier optimizations, an "extensive" one for write barrier
> expansion). I found that in some corner case the simple one fails so now
> I switched to only using the extensive one which caused some massive
> code refactoring. Because of that change I also had to move write
> barrier optimizations to their own pass.
> 
> Performance on the usual benchmarks is unaffected by all of this.
> 
> Roland.
>