RFR: Streamline write-barrier-prologue (C2 part)

[Roman Kennke]

Hey Roland,

>> - it usually loads+checks gc-state 2x back-to-back (null-check is
>> usually known statically)
> 
> Isn't loading 2x the gc state necessary if we want it to fold into the
> heap stable test instruction?

I believe the idea was that we have an outer heap-stable-check that
would be the same regardless of phase (e.g. gc-state == 0), and that
would allow to fold 'happy' paths to single no-barrier path. The 2nd
check is then needed to differentiate between evac (for write-barrier)
and concmark (for satb-barrier). We still do the outer check based on
gc-state, which should still allow happy-path-folding, but the inner
check is replaced by cheaper (because doesn't require additional
gc-state-load) obj == obj' comparison.

>> from cheapest to most expensive:
>> - null-check: cheapest: nothing is loaded. Also, usually elided, and if
>> not, might fold with other nullchecks on same object
> 
> I don't think it will fold that late in the optimization process. By
> putting the null check first, happy path style optimizations are made
> harder. Does it really matter that null check is first?

Not much I guess. In most most most cases the null-check should not
happen anyway: we can only ever do WBs on non-null objects because we
only can store stuff to non-null objects. Exception here is traversal,
where WB can be done for storeval-barrier which requires null-check.

>> - Only 1 region and related phis used for the whole branching stuff
> 
> As I remember the 2 regions were there to help happy path style
> optimizations.

Aha, hmm. So we should keep the regions split then. I can re-work this
accordingly when I'm back from vacation in 1.5 weeks.

Thanks for looking at this!

Roman