RFR: 8166811: Missing memory fences between memory allocation and refinement
kim.barrett at oracle.com
Mon Nov 7 18:36:46 UTC 2016
> On Nov 7, 2016, at 5:57 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> On Sat, 2016-10-29 at 19:26 -0400, Kim Barrett wrote:
>>> On Oct 25, 2016, at 7:13 PM, Kim Barrett <kim.barrett at oracle.com>
>>> Please review this change to address missing memory barriers needed
>>> ensure ordering between allocation and refinement in G1.
>>> [Based on http://cr.openjdk.java.net/~kbarrett/8166607/webrev.02/]
>> 581 // The region could be young. Cards for young regions are
>> 582 // so the post-barrier will filter them out. However, that
>> 583 // is performed concurrently. A write to a young object could
>> 584 // before the card has been dirtied, slipping past the filter.
>> This is a rewording of the comment that used to be here. However, it
>> was not true even before these changes. As part of JDK-8014555 we
>> mark young region cards with g1_young_card_val(). That's the change
>> set that added the storeload to the post-barrier.
>> I'm not quite sure what to do about this. The comment is currently
>> wrong. However, the storeload is considered a problem, and there
>> have been various ideas discussed for eliminating it that might allow
>> us to go back to dirtying young cards.
> Depends on what "dirtying" is supposed to mean in this context -
> setting it to "dirty" or setting it to something non-clean.
> One could replace "dirtied" by something less specific here to make it
> right again.
Good idea. How about this rewording (using “set to a value”)
// The region could be young. Cards for young regions are set to a
// value that allows the post-barrier to filter them out. However,
// that card setting is performed concurrently. A write to a young
// object could occur before the card has been set, slipping past
// the filter.
More information about the hotspot-dev