RFR(S): 7190666: G1: assert(_unused == 0) failed: Inconsistency in PLAB stats
Jon Masamitsu
jon.masamitsu at oracle.com
Tue Aug 28 17:00:21 UTC 2012
Looks good.
On 8/27/2012 5:36 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review the changes for this CR? The
> webrev can be found at:
> http://cr.openjdk.java.net/~johnc/7190666/webrev.0/
>
> Summary:
> The value of PLABStats::_allocated was overflowing and the failed
> assertion detected when it overflowed to 0. When we retired an
> individual allocation buffer, we were flushing some accumulated values
> to the associated PLABStats instance. This was artificially inflating
> the values in the PLABStats instance since we were not reseting the
> accumulated values in the ParGCAllocBuffer after we flushed.
> Ordinarily this would not cause an issue (other than the values being
> too large) but with this particular test case we obtained an
> evacuation failure. As a result we were executing the GC allocation
> slow-path, and flushing the accumulated values, for every failed
> attempted object allocation (even though we were unable to allocate a
> new buffer), and we overflowed. Reseting the sensor values in the
> ParGCAllocBuffer instance after flushing prevents the artificial
> inflation and overflow.
>
> Additionally we should not be flushing the values to the PLABStats
> instance on every buffer retirement (though it is not stated in the
> code). Flushing the stats values on every retirement is unnecessary
> and, in the case of an evacuation, adds a fair amount of additional
> work for each failed object copy. Instead we should only be flushing
> the accumulated sensor values when we retire the final buffers prior
> to disposing the G1ParScanThreadState object.
>
> Testing:
> The failing test case; the GC test suite with +PrintPLAB, and jprt.
>
> Note while testing this I ran into some assertion and guarantee
> failures from G1's block offset table. I've only seen and been able
> (so far) to reproduce these failures on a single machine in the jprt
> pool. I will be submitting a new CR for these failures. I do not
> believe that the failures are related to this fix (or the change that
> enabled resize-able PLABS) as I've been able to reproduce the failures
> with disabling ResizePLAB and setting OldPLABSize=8k, 16k, and 32k.
>
> Thanks,
>
> JohnC
More information about the hotspot-gc-dev
mailing list