RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
david.holmes at oracle.com
Thu Dec 19 17:55:59 PST 2013
Still catching up ...
On 11/12/2013 9:46 PM, Lindenmaier, Goetz wrote:
> 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.
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.
> Please review and test this change.
> Best regards,
More information about the hotspot-dev