RFR (XS): 8054808: Bitmap verification sometimes fails after Full GC aborts concurrent mark
jon.masamitsu at oracle.com
Wed Aug 27 15:55:04 UTC 2014
On 8/27/2014 8:35 AM, Thomas Schatzl wrote:
> On Wed, 2014-08-27 at 08:00 -0700, Jon Masamitsu wrote:
>> Would it work to snapshot the value for end()
>> end =r-> end()
>> and use that instead of calculating "end" from
> not necessarily. As r->_end is not volatile the compiler is free to
> replace any local variable with a re-read of it, resulting in the same
> code and problem as before.
> You would need something like "HeapWord* end = (HeapWord*
> volatile)r->end();" to make sure that this replacement not done by the
> The proposed solution seemed simplest to me, since it avoids thinking
> about what the contents of r->_end could be for the different types of
> E.g. the _end of humongous continues regions == _bottom iirc, so there
> might be cases when we miss checking the bitmap. For example, due to
> timing the code reads r->end() == r->bottom() + HeapRegion::GrainWords
> for a region that has just been changed from Humongous Starts to normal,
> but still gets the r->end() == r->bottom() for humongous continues
> Above might not be possible for various reasons (I remember code at
> least for creating humongous regions that makes sure that the various
> _end values are written in a particular order), but to verify that I
> would have to look in other places.
> The current solution avoids requiring me to reason about this
Thanks. I understand better now.
Change looks good.
More information about the hotspot-gc-dev