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

Jon Masamitsu jon.masamitsu at oracle.com
Tue May 24 19:48:48 UTC 2016



On 5/24/2016 9:59 AM, Kim Barrett wrote:
>> On May 22, 2016, at 10:01 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>> 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.
>>>
>> 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.
> It is possible, and even fairly likely, that the objArray's header is
> not in any relevant dirty range.
>
>> 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.
> That doesn't seem like a very likely scenario to me; timing
> differences between runs could easily result in problems being missed
> until the sweep phase.
>
> OTOH, having spent some time studying old bug reports, I now agree the
> Printezis-bit consistency checks there have real value, and will
> reinstate them.
>
> I'm less convinced about the utility of the interior mark bit
> verification there.  However, there's a way to mostly keep it, while
> strongly reducing the performance impact.  The idea is to record the
> last verified object and only perform the verification if the new
> object differs from that last verified.  So I'll do that too.
>
> New webrev:
> http://cr.openjdk.java.net/~kbarrett/8156548/webrev.01/

Changes look good.

Thanks.

Jon
>
> (No incremental webrev, since this version is pretty much completely
> different.)
>
> Testing:
> Redid local testing to verify performance benefit.
> RBT GC testing with CMS as the collector.
>




More information about the hotspot-gc-dev mailing list