RFR: 8156548: gc/gctests/StringInternSyncWithGC2 fails with Test level exit status: 151

[Joseph Provino]

I never heard of Printezis marks before. Maybe Tony will provide you an 
R review. ;-) assert(size >= 3, "Necessary for Printezis marks to work");

jp

On 5/20/2016 5:24 PM, Kim Barrett wrote:
> Please review this fix for a serious performance bug in non-product
> verification code in CMS precleaning.
>
> When precleaning an object, the mark bits for the object are verified,
> including scanning for invalid set mark bits interior to the object.
> If there are multiple dirty ranges applicable to the object,
> processing each range leads to mark bit verification.  If the object
> is large and there are many applicable dirty ranges, a lot of time may
> be spent on this verification.
>
> For example, in a test that creates many large objArrays (O(64) of
> O(16M) elements) and randomly scribbles on them, we've seen preclean
> times of 20+ minutes because of this.
>   
> This verification isn't precise, since it is performed when the object
> is visited during precleaning.  Not all live objects will require
> precleaning, and this won't catch post-visit mark corruption.  This
> verification is also redundant with that done later, during the sweep
> phase, where it *is* precise.  So the only benefit of the problematic
> verification is that it might catch a problem earlier.
>
> Since the problematic verification is redundant with later checks, we
> simply remove it.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8156548
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8156548/webrev.00/
>
> Testing:
> Locally tested before and after change, using GC logging to see
> precleaning time drop from 15+ minutes to 20 seconds.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160520/07faf1e4/attachment.htm>