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

John Rose john.r.rose at oracle.com
Fri Jan 31 16:10:27 PST 2014

On Jan 30, 2014, at 2:14 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

In pure spec-induced sense, the block emitting the barrier in doexits() is only valid for initializers. That means, @Stable can indeed mimic its constructor store as the final field store. However, piggybacking on the same code to produce the barrier for an arbitrary method seems very error-prone (and even contradicting the comment in doexits() which assumes [wrotefinal == true] => [method.isinitializer() == true]).

Yes, that is right. I think of @Stable as a postponed (post-constructor) final, but making that real will require a write barrier.

Currently, @Stable is only about "sticky" reads. I.e., if you read a non-null value, you can stick with it, as long as you like.

If @Stable writes out the value in an arbitrary method, then it requires release barrier on it's own. It is a pure luck finals also have MemBarRelease, while they could have more relaxed form... especially when/if JMM 9 effort would allow this relaxation. Conflating memory semantics for finals and @Stable seems wrong.

Yes.

Hence, I think the change is sound. It keeps @Stable semantics for constructor stores. @Stable needs more work to emit release barriers for the arbitrary methods if required (why?), and I think given the failure scenario affects only non-TSO platforms, it can be done separately.

Our uses of @Stable (inside java.lang.invoke) are limited to immutable objects or objects with acceptable races.

So existing barriers should be enough. The barrier insertion done by C2 probably has no effect other than forcing the data to settle a little sooner.

If we want to make it available for wider use we may have to make it more bullet-proof. Making it more like "postponed final" would require a write barrier.

— John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140131/b821fac4/attachment.html

More information about the hotspot-compiler-dev mailing list