C2 verification pass shenandoah barriers

[Roland Westrelin]

>> In graphKit.cpp, I changed the Phi input for the object null path at
>> a barrier to be the null object. It could help the compiler optimize
>> code better (and also makes the code of the verification pass
>> simpler)
>
> This was a problem child in the past. I think you noticed that it could
> make the compiler crash, and added the necessary tweaks to avoid that.
> I just hope that we can get the required cast_not_null() stuff
> upstream? Would there be any possible disadvantage in those?

It seems like a reasonable change to me so I would expect it to be
accepted upstream. The only disadvantage I see is an increase in the
number of nodes to represent the same method.

> It's ok to commit if you change the read barriers in acmp to write
> barriers.

I made that change but noticed a bug in the verification code. I'm
redoing some testing.

For the unsafe support I should have mentioned that for a method like
this one (note o is an array):

static void m(Object[] o, long offset) {
    UNSAFE.putObject(o, offset, null);
}

the compiled code emits a null check for o and always deoptimizes if o
is null. I don't think it's safe to change the load to a raw memory load
in that case because the compiler doesn't emit memory barriers around
the memory access when it does for:

static void m(Object o, long offset) {
    UNSAFE.putObject(o, offset, null);
}

Roland.