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

[White, Derek]

Hi David,


The release_set_klass is really only used to create an ordering between the writes to the length field(s) and the klass field. And it's only ordered w-r-t readers that read via load_acquire (as you've been hunting down misuses of load_acquire and store_release!). Only CMS has a dependency on getting that ordering correct.


There's a separate requirement: external threads don't see an object in a partially created state, if for example an object reference escapes before the object zeroing (and initialization?) have committed.


The compilers and interpreter enforce the 2nd requirement via membars (unless they prove that they are unnecessary). There's a claim that the thread-state transitions will do enough membars to keep things safe.  I have no opinion on this.


Given that there are a huge number of unordered reads of the klass field, and only a few ordered reads (really only by CMS), I don't think a store_release is the right way to get what you want though.



- Derek

________________________________
From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> on behalf of David Holmes <david.holmes at oracle.com>
Sent: Sunday, September 11, 2016 9:38 PM
To: Kim Barrett; hotspot-dev Source Developers
Subject: Re: RFR: 8165808: Add release barriers when allocating objects with concurrent collection

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