RFR (S) 8031818: Experimental VM flag for enforcing safe object construction (original) (raw)

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Jan 22 01:12:03 PST 2014

Hi Remi,

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): http://shipilev.net/blog/2014/all-fields-are-final/

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.

-Aleksey.

More information about the hotspot-compiler-dev mailing list