Concurrent collectors (especially CMS) impose constraints on object allocation and header initialization in order to ensure that the concurrent GC can concurrently parse memory in the process of being allocated and initialized by another thread. In particular the klass field of an object must be zero until the length field of an array or class instance has been set. In the general case, the allocating code has to set the klass field with a store-release and concurrent GC thread has to read the klass field with a load-acquire.

But this does NOT require that the inline-allocation code in the interpreter or jitted code (much of which is processor-dependant) has to do the same. This is because the inline allocation code only allocates within the young gen (either in TLABs or eden space), while the concurrent GC is only concerned with scanning object in the old gen. So there is no need to ensure memory order consistency.

But this is not well documented or verified with assertions, and some of the processor-dependant runtime code attempts to meet these constraints.

This needs to be fixed with more definitive comments, assertions, and removing some confused comments.