RFR(M/L): 6484982: G1: process references during evacuation pauses
john.cuthbertson at oracle.com
Wed Aug 3 10:44:49 PDT 2011
A new webrev incorporating some feedback from Ramki can be found at:
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
> 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').
More information about the hotspot-gc-dev