RFR(s): 8171449" [aarch64] store_klass needs to use store release
kim.barrett at oracle.com
Wed Dec 28 22:53:59 UTC 2016
> 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
> 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
More information about the hotspot-runtime-dev