RFR: enqueue barrier + some other things

[Roman Kennke]

As far as I can tell, the changes are ok. It will enable some
interesting optimizations (that are not yet in this patch). Thank you!

One question: the EQ barrier node replaces the incoming value. But it
doesn't itself produce any new value (like RB/WB do), does it?


We shall introduce some GC interfaces for some of the important hooks,
and fold some other stuff into existing GC interfaces, but this is
unrelated to this patch. As always: please upstream stuff that you think
makes sense to upstream. Given that it takes ages to get anything c2
upstream, better to start as early as possible.

- Here is a stray newline:
http://cr.openjdk.java.net/~roland/shenandoah/enqueue-barrier/webrev.00/src/hotspot/share/opto/graphKit.cpp.udiff.html

- Sure you need the 'class MemoryFixer' there?
http://cr.openjdk.java.net/~roland/shenandoah/enqueue-barrier/webrev.00/src/hotspot/share/opto/loopnode.hpp.udiff.html

Thank you!
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.
>