RFR (S) 8031818: Experimental VM flag for enforcing safe object construction
aleksey.shipilev at oracle.com
Wed Jan 22 01:12:03 PST 2014
On 01/22/2014 12:44 PM, Remi Forax wrote:
> My mail is a little OT but anyway, Aleksey, I don't understand why the
> performance are not mostly identical.
...modulo quality of implementation issues. Rigorously quantify the
real-world impact is the rationale of introducing this experimental
feature in the mainline VM. This is what we learned so far (in progress;
so unless you are really anxious and bored, don't read it yet):
> Correct me if I'm wrong, for TSO architecture, you basically do nothing
> so no impact.
Right, but also prohibit the compiler reorderings, which can matter.
> For ARM or PPC, you need a barrier but anyway you need to
> emit a barrier when you store the class pointer in the header of the
> object, so it should not perf at all the JIT is able to see that the
> class pointer is not read in the constructor
There is also the tidbit: securing the field stores with StoreStore is
arguably not enough, which is why C2 emits MemBarRelease
(LoadStore+StoreStore) at the end of constructor. It is heavier than
ordinary StoreStore, at least for ARMs.
Anyhow, fixing this requires StoreStore/(LoadStore+StoreStore) barrier
coalescing logic, which is still missing. The performance model in the
absence of smart optimizing compiler is still of interest in spec work.
More on that later.
More information about the hotspot-compiler-dev