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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Jan 16 10:15:39 PST 2014

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?

Thanks, Vladimir

On 1/15/14 9:30 PM, David Holmes wrote:

Can I get some response on this please - specifically the redundancy wrt IRTENTRY 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