RFR (M): JDK-8043239: G1: Missing post barrier in processing of j.l.ref.Reference objects

[Per Liden]

Looks good to me Bengt.

Even if this means we sometimes dirty too many cards this looks like a 
much less error-prone approach, which I like.

/Per

On 06/02/2014 04:30 PM, Bengt Rutisson wrote:
>
> Hi all,
>
> Can I have a couple of reviews for this change?
>
> http://cr.openjdk.java.net/~brutisso/8043239/webrev.00/
>
> https://bugs.openjdk.java.net/browse/JDK-8043239
>
> As described in the bug report the reference processor was missing a
> write barrier call when manipulating the discovered list. This has
> always been the case but it was hidden because at the end of the
> reference processing we went through the complete discovered list and
> dirtied all the missed cards because we did an (unnecessary) write
> barrier when we set the next field to point to be a self pointer
> pointing back at the reference object itself.
>
> The write barrier for setting the next field was removed since it was
> not needed, but that revealed the current bug. After some discussions
> and prototyping we came to the conclusion that there may be more
> barriers missing and that it is difficult to get the dirtying done the
> way our verification code assumes. A simpler solution seems to be to
> free the reference processing of all barriers and instead just make sure
> that we dirty all the right cards in the last pass.
>
> The proposed fix thus re-introduces the post barrier when we iterate
> over the discovered list. This time it uses the discovered field for the
> barrier to be more explicit about what is going on.
>
> Testing:
> JPRT,
> Kitchensink, 5 days
> GC test suite
> SPECjbb2013
> Ad-hoc aurora run
> Specific reproducer that illustrated the problem.
>
> The specific reproducer was really good to pinpoint the problem but is
> hard to turn in to a JTreg test. Many thanks go to StefanK for helping
> out with creating the reproducer.
>
> Thanks,
> Bengt