RFR(S): G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054

[Ramki Ramakrishna]

Looks good to me, John. I also like the fact that this is now more in 
line with how
other collectors do reference discovery in hotspot (i.e. those objects 
not in
the collection set are not eligible for discovery; of course the mixed 
(young+old)
collections of G1 pose a different challenge, as you've outlined elsewhere).

Thanks also for the explanation of the race which triggered the assert.

-- ramki

> Hi Everyone,
>
> Can I have a couple of volunteers to review the changes for this CR? 
> The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7097053/webrev.0/
>
> Summary:
> During RSet scanning the reference processor was discovering a 
> reference oop whose referent object failed the is_oop() test in the 
> failing assert. It appears that is was being caused by a race between 
> RSet updating (which did not perform reference discovery) and RSet 
> scanning (which did) and so the reference processor could see a 
> referent object that was in the process of being copied. To resolve 
> this issue we have decided to not do reference discovery duing RSet 
> scanning.
>
> Testing: The failing test case (with a 1ms delay between object 
> forwarding and copying - which increases the frequency of hitting the 
> assert almost 3x) on highly threaded SPARC T2 systems; OpenDS on x64.
>
> Thanks,
>
> JohnC