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

[David Holmes]

On 17/01/2014 4:15 AM, Vladimir Kozlov wrote:
> Changes are in C++ Interpreter so it does not affect Oracle VM.
> But David has point here. I would like to hear the explanation too.
>
> BTW, I see that for ppc64:
>
> src/cpu/ppc/vm//globals_ppc.hpp:define_pd_global(bool, UseMembar, false);
>
> as result write_memory_serialize_page() is used in
> ThreadStateTransition::transition().
>
> Is it not enough on PPC64?

You would need to consult a PPC64+linux expert to be certain but what I 
was basically told is that the serialization page mechanism is only 
guaranteed to work for TSO systems.

David
-----


> Thanks,
> Vladimir
>
> On 1/15/14 9:30 PM, David Holmes wrote:
>> 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.
>>>>