(original) (raw)
On Jan 30, 2014, at 2:14 PM, Aleksey Shipilev <aleksey.shipilev@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