RFR: enqueue barrier + some other things

[Roman Kennke]

Hi Roland,

one thing:

doesn't static-null-checking like this:

  if (val_t->meet(TypePtr::NULL_PTR) == val_t) {

require remove_speculative() or such?

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.
>