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.


> Please review and test this change.
> Best regards,
>    Goetz.

More information about the hotspot-dev mailing list