I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as I don't think compiler can prove that it's safe to do so. When value types come to be and get scalarized, it may be possible to create cheap synchronization types that are stack allocated yet are used for synchronization control. For example, C# has a SpinLock struct ( https://msdn.microsoft.com/en-us/library/system.threading.spinlock%28v=vs.110%29.aspx ).
Also, I don't think Unsafe induced fences are part of JMM, current or future (at least I haven't heard that to be the case). sent from my phone On Feb 18, 2015 5:11 AM, "Andrew Haley" <a...@redhat.com> wrote: > On 02/18/2015 10:01 AM, Andrew Dinn wrote: > > On 17/02/15 19:21, Vitaly Davidovich wrote: > >> IMO I don't think such barriers should be removed just because EA is > able > >> to elide the heap allocation. > > > > Why not? Are you assuming that the programmer might be relying on a > > memory barrier being implied in interpreted/JITted code by the presence > > in the source of an allocation? If so then I am not sure the Java memory > > model justifies that assumption, especially so in the case EA optimises. > > It doesn't. > > There are essentially two ways to prevent unsafe publication of > objects with final fields: either emit a barrier at the end of the > constructor or track the reference to the newly-constructed object > until it is stored in memory. That store to memory can be a releasing > store. If the object does not escape that releasing store can be > eliminated. > > Andrew. >
