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

[Bengt Rutisson]

On 6/2/14 4:57 PM, Per Liden wrote:
> 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.

Thanks for the quick review, Per!

Bengt

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