RFR: 8165808: Add release barriers when allocating objects with concurrent collection
david.holmes at oracle.com
Mon Sep 12 01:38:26 UTC 2016
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
> 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.
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.
> Local jtreg tests.
More information about the hotspot-dev