RFR(s): 8171449" [aarch64] store_klass needs to use store release

Kim Barrett kim.barrett at oracle.com
Tue Dec 27 21:21:54 UTC 2016

> On Dec 27, 2016, at 5:40 AM, Andrew Haley <aph at redhat.com> wrote:
> If we really did want to do this on AArch64, we could better by
> zeroing the object first, writing the length field, then storing the
> klass field with stlr.  One fence rather than two would be better than
> what we do at the moment, which is storing the klass field then
> zeroing the object. 

I think zeroing the object is intentionally delayed.

In the slow path, the allocation of a raw chunk of memory is done
while holding the Heap_lock.  That lock prevents other Java threads
from entering the slow path.

Part of that raw chunk allocation makes the chunk unavailable to other
Java threads.  But it also makes the chunk visible to a concurrent GC.
Hence the need to first zero out what will eventually be the klass
field.  The concurrent GCs use this as a marker that this memory is in
the process of becoming an object, but isn't sufficiently far along to
look at the contents.

It is important to minimize the lock duration, to allow other Java
threads to enter the slow allocation path.  By delaying the zeroing of
the object, we're trading more memory barriers to reduce the lock
duration.  While locally better, reducing the number of barriers by
moving the object zeroing into the lock region seems likely to be
globally worse.

More information about the hotspot-runtime-dev mailing list