RFR(s): 8171449" [aarch64] store_klass needs to use store release
thomas.schatzl at oracle.com
Wed Dec 21 16:00:47 UTC 2016
On Wed, 2016-12-21 at 15:46 +0000, Andrew Haley wrote:
> 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.
That is what confused me, because the original context to me seemed to
talk about G1. So my answer is applicable to G1 only, sorry.
I will see if I can find out how CMS works (or is supposed to) in that
More information about the hotspot-runtime-dev