RFR: 8166862: CMS needs klass_or_null_acquire

[White, Derek]

Thanks for the info Kim. Yes,  my comments are not relevant to this bug.

- Derek

On Oct 5, 2016, at 8:26 PM, Kim Barrett <kim.barrett at oracle.com> wrote:

>> 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.
>