2. Initialization of volatiles in constructors
  [0] enter constructor
  [1] store volatilefield
  [2] ... other stores of fields ...
  [3] exit constructor
We want to replace StoreLoad fence after [1] with StoreStore

We may also want to emit a single final StoreStore instead of several of them. Note that this should also remove the mfence since StoreLoad is the only membar which actually emits any code.
Doug Lea wrote:
> John Rose wrote:
>> On Nov 4, 2007, at 11:55 PM, John Rose wrote:
>>
>> Actually, the "no fence 2" spot has an IR node called Initialize,
>> which serves as a CPU order memory barrier, and perhaps
>> also ought to be a StoreStore barrier where needed.
>>
>
> Sigh-of-relief. Thanks for looking into this!

The initialize node only exists in 1.7 so if there's a real problem here then it exists in all other releases. I'm unclear why the initialize node matters though. The inline initialization of newly allocated storage always occurs in the trailing part of one side of a diamond which is before the constructor so it's impossible for the compiler to move those stores down into the constructor. The memory phi merging the initializing stores on one side with the resulting memory state of the slow path allocation keeps that from happening. John's change is collecting other initializing stores from the constructor so I don't see how it affects the original concern. Are you saying it's need for platforms with a relaxed memory model so we have a place to emit a storestore membar instruction?

tom

> Tom: Maybe you could adjust this to be a true membarRelease while
> working on the other fence stuff? That would remove all doubt here.
>
> -Doug
>
>

Right. I'll modify the InitializeNode to be equivalent to a membar release in the optimization of volatile stores in the constructor. Also we decided that if a constructor for an object with volatiles has no explicit stores to it's volatile fields then it needs a trailing StoreStore so I'll include that as well.

tom

Doug Lea wrote:
> Tom Rodriguez wrote:
>> Are you saying it's need for platforms with a relaxed memory model so we have
>> a place to emit a storestore membar instruction?
>>
>
> I guess my main point is that whenever you have an ordering
> constraint, you logically need one of the flavors of membar.
> On machines with strong enough orderings, some eventually
> disappear into nothingness. But I'd think that consistently
> using them means fewer special cases elsewhere, and more
> likelihood of success for ports to PPC, IA64, ARM, etc., if
> you ever suddenly start caring about such things.
>
> -Doug
>
>
>
>