RFR: 8166862: CMS needs klass_or_null_acquire

[Kim Barrett]

> On Oct 5, 2016, at 7:36 PM, White, Derek <Derek.White at cavium.com> wrote:
> 
> Thanks for the reminder Kim! (Boy, you walk away from this code for a few days...)
> 
> So we have the case where the slow-path "runtime" allocators always do a store_release on the klass (if CMS might run), but never do a StoreStore barrier after initializing the object fields/elements. The interpreter/compilers are responsible for that (typically done by generated code).

Yes, except G1 also needs the release_store of the klass.

> That leaves other runtime callers of the CollectedHeap allocators to also make sure that they have the correct barriers.

Yes.

> It's not yet clear that they do. It might help to separate allocators directly called by the interpreter/compiler. Here's a 2-deep fan-out:
> 	InstanceMirrorKlass::allocate_instance
> 	InstanceKlass::allocate_instance
> 	ArrayKlass::allocate_arrayArray
> 	InstanceKlass::allocate_objArray
> 	- oopFactory::new_objArray
> 	ObjArrayKlass::allocate
> 	- Deoptimization::realloc_objects
> 	- oopFactory ::new_objectArray
> 	TypeArrayKlass::allocate_common
>  	- oopFactory::new_metaDataArray
>  	- oopFactory::new_typeArray_nozero (OK)
> 	JVM_Clone (OK?).

Maybe there are some missing, and maybe not.  But that’s not relevant to *this* bug, which is about the setting of klass and access to it by concurrent collectors..  I’m trying to get the fix for *this* bug reviewed.