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

[Andrew Haley]

On 21/12/16 12:22, Thomas Schatzl wrote:
> Hi Andrew,
> 
> On Tue, 2016-12-20 at 16:42 +0000, Andrew Haley wrote:
>>
>> On 20/12/16 14:40, White, Derek wrote:
>>
>>> As far as which GCs need to worry about this goes, CMS is clearly
>>> in
>>> danger with this issue on weak memory model systems. I don't have a
>>> definitive answer for G1. Thomas makes a good argument that in G1,
>>> concurrent GC would only scan a newly allocated object if it were
>>> humongous, and there are enough memory barriers around allocating a
>>> humungous region that we should be safe. But there were changes
>>> made
>>> to G1 to use oopDesc:: klass_or_null_acquire(). See
>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1a33f585a889
>>> . Perhaps these are overly conservative?
>>
>> After an object is allocated and before it is zeroed, the object is
>> garbage.  This includes the klass field, which probably is non-null.
>> There is a window in time between the memory being allocated and the
>> klass field being written.  So, I suppose until the klass field is
>> written, some memory which is about to become an array must not be
>> visible to CMS.  It must not be visible because it must not be
>> possible for CMS to see a garbage klass field.
> 
> s/CMS/G1?

No.  I traced through CMS allocation.  At least, I traced through
allocating a large array with CMS enabled.

> At that point "top" of the region must be the same as "bottom" in this
> case. To be allocated, a region must have been "Free" before that; we
> set to "Free" and reset a regions' "top" to "bottom" only during STW
> pause, so this must be visible.

This is what I don't understand.  When memory is allocated for an
object, it immediately becomes visible to a concurrent collector.  Is
this so?  If it is not so, then there is no problem which needs a
fence between setting the size field and the klass field, because the
object is garbage anyway.  If it is so, then there is a real problem
because the collector will see garbage before the size field and the
klass field are written.

Surely it must be one or the other.  Or maybe I've found an actual
bug.

All I'm asking is this question which I think is very simple: when
does allocated memory become visible to a concurrent collector?  Is it
when the memory is allocated, or is it later?  If is is later, what
makes it visible?

> So this card will be filtered out by the gc thread and that area not
> scanned, the check is at g1RemSet.cpp:668. Also see the comment at line
> 659.

That's G1, I think.

Andrew.