RFR (S): 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization
David Holmes
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:
> 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.
>
More information about the ppc-aix-port-dev
mailing list