RFR(s): 8029255: G1: Reference processing should not enqueue references on the shared SATB queue

[Per Liden]

Thanks Bengt!

The bug is updated with the alternatives we discussed.

/Per

On 2014-01-08 14:42, Bengt Rutisson wrote:
>
> Looks good, Per!
>
> For the record, Per and I discussed a couple of different options to 
> solve this issue but came to the conclusion that the current patch is 
> the better option for now. Per will document the other options in the 
> bug report.
>
> Bengt
>
>
> On 2013-11-28 17:50, Per Liden wrote:
>> Summary: A side effect of fixing JDK-8029162 (G1: Shared SATB queue 
>> never enabled) is that the reference processor will start to add 
>> references to the shared SATB queue when enqueuing discovered 
>> references. This will later cause 
>> ConcurrentMark::verify_no_cset_oops() to fail because we now have 
>> enqueued references in the SATB qeueue which points into the 
>> collection set (which will be empty after the collection). This patch 
>> makes sure we avoid doing pre-barriers, by instead doing raw stores 
>> followed by a post-barrier.
>>
>> This patch also removes an unused constructor and the unnecessary 
>> caching of the barrier set in the ReferenceProcessor. So use of _bs 
>> was replaced by oopDesc::bs(). Further, the cached barrier set was 
>> only set/used if discovered_list_needs_barrier was true, but with 
>> this change we will need the barrier set in other cases too.
>>
>> Testing done: jprt, kitchensink (10 hours), gcbasher (10 hours)
>>
>> http://cr.openjdk.java.net/~pliden/8029255/webrev.0/
>>
>> https://bugs.openjdk.java.net/browse/JDK-8029255
>>
>> cheers,
>> /Per
>