RFR: 8166862: CMS needs klass_or_null_acquire

[David Holmes]

Hi Kim,

On 2/10/2016 7:29 AM, Kim Barrett wrote:
> Please review this change to the CMS collector to replace uses of
> klass_or_null with klass_or_null_acquire where needed.
>
> [Reviewing on hotspot-dev; only GC code is involved, but some non-GC
> folks have expressed interest.]
>
> All non-assert uses of klass_or_null are being replaced with the
> acquire variant.  In most cases, the size is being accessed soon
> after, and the acquire is needed to ensure order of klass and possible
> inline size access.  In a few cases, the need for acquire is less
> immediately obvious:
>
> - CompatibleFreeListSpace::block_is_obj - Size access is not lexically
>   apparent, but callers access the size or other data ordered with the
>   klass.
>
> - MarkFromRootsClosure::do_bit and ParMarkFromRootsClosure::do_bit:
>   These perform other operations that need to be properly ordered wrto
>   the klass access.

Can you point me to the release-store that is being paired with these 
load-acquires please?

Superficially this all seems fine and can't have any correctness issues, 
it is just a matter of where acquire semantics are actually needed. And 
it is hard to tell that without understanding exactly how the different 
read-paths may execute relative to the write-path.

Thanks,
David

> Removed a couple of explict acquire fences that are made redundant by
> the use of klass_or_null_acquire.  The latter is preferable, as it
> permits the use of platform-specific load_acquire implementations that
> might be better than separate load + acquire fence.
>
> Removed a stale comment about permgen and is_parsable.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8166862
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8166862/webrev.00/
>
> Testing:
> JPRT
>