RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
vitalyd at gmail.com
Wed Feb 18 14:16:59 UTC 2015
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 (
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" <aph at 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
> >> 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
More information about the hotspot-dev