RFR: 8166811: Missing memory fences between memory allocation and refinement
Thomas Schatzl
thomas.schatzl at oracle.com
Tue Nov 8 10:01:53 UTC 2016
Hi Kim,
On Mon, 2016-11-07 at 14:07 -0500, Kim Barrett wrote:
> >
> > On Nov 7, 2016, at 1:36 PM, Kim Barrett <kim.barrett at oracle.com>
> > wrote:
> > >
> > > >
> > > >
[...]
> > > 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.
> Oops, no, that isn't right. (It's been a couple of weeks since I
> looked at this, and forgot part of the problem.)
>
> Part of what's wrong with the comment is that we can no longer get to
> that point with a young region. A young region's cards will be ither
> g1_young_gen or clean, never dirty. Hence the filtering out of non-
Why? I think the reason for this comment has been that the following
could happen:
A: allocate new young region X, allocate object, storestore, stops at
the beginning of the dirty_young_block() method
B: allocate new object B in X, set B.y = something-outside, making the
card "Dirty" since thread A did not actually start doing
dirty_young_block() yet.
Refinement: scans the card; since R does not seem to synchronize with A
either, you may get a "dirty" card in a young (or free, depending on
whether the setting of the region flag in X has already been observed -
but it must be either one) region here in this case?
A: does the work in dirty_young_block()
(The previous is_young() check has indeed been wrong, and
is_old_or_humongous() is better)
> dirty cards a few lines before this comment will have already
> discarded a young card before we reach the test this comment is
> discussing. So the whole premise of the comment in question, that
> the region could be young, is false.
I think the comment is good after all. I would even emphasize the act
of setting it to "g1_young_gen" by writing something like:
// The region could be young. Cards for young regions are set to
// "g1_young_gen" so the post-barrier will filter them out. However,
// that dirtying is performed concurrently. A write to a young object
// could occur in the same region before the cards have been set to
// that value, slipping past the filter.
Because then, if somebody removes g1_young_gen, he will hopefully find
this place again by searching for "g1_young_gen" and think about this
situation again. (in theory :))
Thanks,
Thomas
More information about the hotspot-dev
mailing list