RFR(M/L): 6484982: G1: process references during evacuation pauses

[John Cuthbertson]

Hi Everyone,

A new webrev for these changes can be found at: 
http://cr.openjdk.java.net/~johnc/6484982/webrev.2/

The changes in this webrev reverse the order of preserving objects 
referenced from the concurrent mark ref processor's discovered lists and 
processing references discovered by the STW ref processor. Preserving 
the objects referenced from the concurrent mark ref processor's 
discovered lists comes first so that any object that needs to be copied 
is done so before reference processing.

JohnC

On 08/03/11 10:44, John Cuthbertson wrote:
> Hi Everyone,
>
> A new webrev incorporating some feedback from Ramki can be found at: 
> http://cr.openjdk.java.net/~johnc/6484982/webrev.1/
>
> Thanks,
>
> JohnC
>
> On 06/23/11 14:35, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> I would like to get a couple of volunteers to review the code changes 
>> for this CR - the webrev can be found at 
>> http://cr.openjdk.java.net/~johnc/6484982/webrev.0/
>>
>> Summary:
>> G1 now contains 2 instances of the reference processor class - one 
>> for concurrent marking and the other for STW GCs (both full and 
>> incremental evacuation pauses). For evacuation pauses, during object 
>> scanning and RSet scanning I embed the STW reference processor into 
>> the OopClosures used to scan objects. This causes reference objects 
>> to be 'discovered' by the reference processor. Towards the end of the 
>> evacuation pause (just prior to retiring the the GC alloc regions) I 
>> have added the code to process these discovered reference objects, 
>> preserving (and copying) referent objects (and their reachable 
>> graphs) as appropriate. The code that does this makes extensive use 
>> of the existing copying oop closures and the G1ParScanThreadState 
>> structure (to handle to-space allocation).
>>
>> The code changes also include a couple of fixes that were exposed by 
>> the reference processing:
>>  * In satbQueue.cpp, the routine 
>> SATBMarkQueueSet::par_iterate_closure_all_threads() was claiming all 
>> JavaThreads (giving them one parity value) but skipping the VMThread. 
>> In a subsequent call to Thread::possibly_parallel_oops_do, the Java 
>> threads were successfully claimed but the VMThread was not. This 
>> could cause the VMThread's handle area to be skipped during the root 
>> scanning.
>>  * There were a couple of assignments to the discovered field of 
>> Reference objects that were not guarded by _discovery_needs_barrier 
>> resulting in the G1 C++ write-barrier to dirty the card spanning the 
>> Reference object's discovered field. This was causing the card table 
>> verification (during card table clearing) to fail.
>>  * There were also a couple of assignments of NULL to the next field 
>> of Reference objects causing the same symptom.
>>
>> Testing: The GC test suite (32/64 bit) (+UseG1GC, +UseG1GC 
>> +ExplicitGCInvokesConcurrent, +UseG1GC 
>> InitiatingHeapOccupancyPercent=5, +UseG1GC +ParallelRefProcEnabled), 
>> KitchenSink (48 hour runs with +UseG1GC, +UseG1GC 
>> +ExplicitGCInvokesConcurrent), OpenDS (+UseG1GC, +UseG1GC 
>> +ParallelRefProcEnabled), nsk GC and compiler tests, and jprt. 
>> Testing was conducted with the _is_alive_non_header field in the STW 
>> ref procssor both cleared and set (when cleared, more reference 
>> objects are 'discovered').
>>
>> Thanks,
>>
>> JohnC
>