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

[John Cuthbertson]

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