RFR: 8165808: Add release barriers when allocating objects with concurrent collection

[David Holmes]

Hi Kim,

On 11/09/2016 8:59 AM, Kim Barrett wrote:
> Please review this change to add release barriers when allocating
> objects that may be visible to a concurrent collector.
>
> This change only addresses the allocation side, where the
> initialization occurs; other subtasks of JDK-8160369 will address the
> (mostly GC-specific) readers that need to accomodate in-progress
> allocations.
>
> As part of this change, eliminated post_allocation_install_obj_klass,
> which consisted of a call to [release_]set_klass + assertions that are
> redundant with those in that called function.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8165808
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8165808/webrev.00/

src/share/vm/gc/shared/collectedHeap.inline.hpp

Based on experiences with RMO architectures (ref JDK-8033920 - sorry it 
is a non-open bug report) I would expect the use of release_set_klass to 
be unconditional, not dependent on the nature of the GC. Publication of 
the object reference also has to be safe for other mutator threads. I'm 
not convinced by the brief argument in JDK-8033920 that thread-state 
transitions will always ensure visibility and ordering.

Thanks,
David

> Testing:
> Local jtreg tests.
>