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

David Holmes david.holmes at oracle.com
Wed Jan 15 21:30:23 PST 2014

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 IRTENTRY 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 handlereturn 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 hotspot-dev mailing list