RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization

[David Holmes]

Can I get some response on this please - specifically the redundancy wrt 
IRT_ENTRY actions.

Thanks,
David

On 20/12/2013 11:55 AM, David Holmes wrote:
> Still catching up ...
>
> On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> this change adds StoreStore barriers after object initialization and
>> after constructor calls in the C++ interpreter.  This assures no
>> uninitialized
>> objects or final fields are visible.
>> http://cr.openjdk.java.net/~goetz/webrevs/8029957-0-moci/
>
> The InterpreterRuntime calls are all IRT_ENTRY points which will utilize
> thread state transitions that already include a full "fence" so the
> storestore barriers are redundant in those cases.
>
> The fastpath _new storestore seems okay.
>
> I don't know how handle_return gets used to know if it is reasonable or
> not.
>
> I was trying, unsuccessfully, to examine the same code in the
> templateInterpreter to see how it handles these cases as it naturally
> has the same object-initialization-safety requirements (though these can
> be handled in a number of different ways other than an unconditional
> storestore barrier at the end of the initialization and construction
> phases.
>
> David
> -----
>
>> Please review and test this change.
>>
>> Best regards,
>>    Goetz.
>>