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

[Thomas Schatzl]

On Tue, 2016-12-20 at 10:27 +0000, Andrew Haley wrote:
> On 20/12/16 10:21, Thomas Schatzl wrote:
> > 
> > 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.
>
> Yeah.  This stuff doesn't make any sense: I need to see the code.  I
> guess that what's going on is that a humongous object is allocated,
> the memory is zeroed, and the memory is then returned to the Java
> thread, which then initializes the object.  So, the object is
> reachable from the GC thread even before it has been initialized.  
> But instances of Class aren't humongous... or are they?

  you can have instances of regular classes that are humongous. :)
There is no limitation on object instance size in the language spec
afaik, but at least it allows as large objects as to qualify as
humongous.

In any case, G1 only ever allocates humongous objects in old gen which
makes things a lot easier because these regions can only ever contain
that single humongous object and nothing else useful. And we only need
to take care about appropriate memory barriers in the runtime because
humongous objects are always allocated in the runtime.

As for the patch, this changes the generated fast-path eden allocation
code, so to be of any problem for the interaction with the concurrent
gc threads, the runtime would first have needed to hand out "TLABs"
from old gen.

G1 never does that, so the patch does not seem to be applicable for it
at all, but I think for CMS this seems different. The TLAB allocator
for CMS can hand out old gen "TLABs" in some cases, e.g. when the
GCLocker prevents an immediate GC when running out of space (I did not
confirm this particular case yet).

So Derek, can you elaborate a bit on what error case you have in mind?

Thanks,
  Thomas