RFR: 8073717: verify_no_cset_oops found reclaimed humongous object in SATB buffer

[Kim Barrett]

On Apr 14, 2015, at 1:00 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this change to remove some no longer valid checking of
> the SATB buffers.
> 
> During an evacuation pause there are several points where the contents
> of the SATB buffers (along with other data structures not relevant
> here) are examined to verify they don't contain objects that are in
> the collection set.  The introduction of eager reclaim of humongous
> objects may result in violations of the "invariant" being checked,
> when applied to the SATB buffers.
> 
> This is related to other issues around stale references to reclaimed
> humongous objects being present in the SATB buffers.  See also
> https://bugs.openjdk.java.net/browse/JDK-8075466.
> 
> Rather than doing extra work to scrub the stale references from the
> buffers, we are going to handle them lazily - the needed tests are
> already being performed by the final processor of the SATB buffers as
> part of object marking.  This means that invariants about the contents
> of the SATB buffers need to be relaxed.
> 
> To deal with this particular case, where verify_no_cset_oops is
> failing, we are changing to no longer have that function examine the
> SATB buffers at all.  Removing that checking then leaves some
> functions for the SATB queues unused, so we delete them too.
> 
> As a result, one of the three calls was checking state that hadn't
> changed since the previous check, so was removed.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8073717
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8073717/webrev.00/
> 
> Testing:
> JPRT

Please ignore this review request.  I’ll be sending out a new request shortly, under a different (non-confidential) bug number.