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

Jon Masamitsu jon.masamitsu at oracle.com
Mon May 23 02:01:16 UTC 2016



On 5/20/2016 2: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.

Instead of eliminate the verification can you leave it in for non-object 
arrays?
You might be able to do the verification for the object array once if 
you did it
only when an object header was in the dirty range but do it for the 
length of
the entire object array.

If the verification were to consistently fail here and never fail when 
done during
the sweep, I think that bounds where in the code we need to look for a 
problem.

Jon

>
> 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.
>




More information about the hotspot-gc-dev mailing list