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

[John Rose]

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 do_exits()
> 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 do_exits() which
> assumes [wrote_final == true] => [method.is_initializer() == 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
> MemBar_Release, 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