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

[Thomas Schatzl]

Hi,

On Tue, 2016-12-20 at 09:21 +0000, Andrew Haley wrote:
> On 20/12/16 09:14, Thomas Schatzl wrote:
> > 
> > > 
> > > > 
> > > > 
> > > I'm a bit baffled by the reasoning behind all of this.  If a Java
> > > thread isn't finished initializing an array then it's not
> > > reachable from another thread. 
> >   you are probably missing a "Java" between "another" and "thread"
> > here to make this statement correct ;)
> > 
> > The concurrent garbage collectors may scan areas of the heap that
> > is currently being allocated into.
>
> Those areas of the heap contain garbage before an object is
> initialized.  They can be pointers into the middle of an object,
> fields that contain longs which look like object pointers, and so on.
> Anything is possible: it's just memory.  Or do the concurrent
> collectors scrub the memory being allocated into?

Having a NULL klass value is not the only information the concurrent
collectors use for determining whether they can safely scan an area.

Further, there are a lot of limitations on what can happen in what
order depending on the collector.

Derek can very likely tell you more about the protocol between CMS'
concurrent threads and the mutators, but both collectors have protocols
to ensure that the memory contains valid information, either retrying
later (G1), or busy waiting (CMS, afaics from code around a "bugfix for
systems with weak memory model" comment) until this is the case.

> > Setting the object's klass field means to them that the members of
> > the particular object have been completely initialized and can be
> > parsed by the GC thread(s).
> So how does a concurrent GC know that a klass field has been written,
> and does not contain leftover garbage?

These threads don't scan random memory, and there is other metadata (in
case of G1, the region type for that area, CMS seems to have indicators
in its lists) that tell whether the area must either contain a NULL or
a valid klass pointer at a specific location.

Please look at the discussions for the referenced https://bugs.openjdk.
java.net/browse/JDK-8160369 and its sub-tasks about this for detail
about possible orderings and the responses etc. Me trying to explain
all the interactions off-hand will surely miss the important, finer
details.

In case of g1, the participants in this dance are the java threads
allocating a humongous object
(G1CollectedHeap::humongous_obj_allocate_initialize_regions), the write
barrier and the refinement queues.
On the reader side, please have a look at G1RemSet::refine_card() and
HeapRegion::oops_on_card_seq_iterate_careful()/do_oops_on_card_in_humon
gous(). The code contains fairly useful comments I think.

Feel free to ask specific questions though. One more pair of eyeballs
is always appreciated.

Thanks,
  Thomas