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

[Kim Barrett]

> On Dec 28, 2016, at 4:54 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 27/12/16 21:21, Kim Barrett wrote:
>>> 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.
> 
> Absolutely so.  I was talking about the fast path.

I think I see.  Where you earlier said "We could argue that we should
stick to this contract with the collectors: ...", you were saying one
might argue that the TLAB context (fast path) should be covered by the
same contract as the slow path, but then counter-argued that this
would introduce more membars.  And the part about zeroing the object
first was a mitigation of the extra membars.  Is that correct?  If so,
sorry I didn't get that earlier.  And yes, applying the same slow-path
contract to the fast path would be bad; doing so would defeat the
whole point of TLAB allocation, which is to avoid all the costs
arising from concurrency by using thread-local data to be explicitly
non-concurrent.