RFR(L): 6484965: G1: piggy-back liveness accounting phase on marking

John Cuthbertson john.cuthbertson at oracle.com
Tue Nov 15 18:44:39 UTC 2011


Hi Everyone,

I have a new webrev for these changes which includes all the code review 
comments made during the code walkthrough and subsequently. The new 
webrev can be found at: http://cr.openjdk.java.net/~johnc/6484965/webrev.1/

Changes include:
* Accessor function type changes (they return a pointer to the card 
bitmap for a task rather than a reference).
* A card bitmap and marked_bytes array is now embedded into the CMTask 
to avoid an extra dereference.
* Marking and counting have been combined in a single operation.
* Mark/count routines have been placed in the .inline.hpp file.
* Aggregation is now down in parallel and clearing of the count data is 
performed at the same time.
* GC Lab retirment - there's no need to be super accurate - I don't need 
a specific routine - and can use one of the existing count routines 
(count_region).

Note this version of the code still has a card bitmap per task/worker id 
and so incurs a footprint penalty. Removing the card bitmap(s) used to 
scrub RSets will be done as a separate change.

Testing: GC test suite and Kitchensink with a very low marking threshold 
- 2%.

Thanks,

JohnC

On 10/03/11 16:09, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review the changes for this CR? The 
> webrev can be found at: http://cr.openjdk.java.net/~johnc/6484965/webrev.0/
>
> Summary:
> During some big application runs we were seeing some excessively long 
> concurrent counting times. These long counting times were increasing the 
> cycle time of concurrent marking and increasing the risk of evacuation 
> failure. It was suggested that, rather than having a separate phase that 
> walks the marking bitmap to calculate the amount of live data etc, we 
> could track this information in some per marking task/worker thread data 
> structures and update the information as objects were marked. These 
> changes implement that scheme. The original bitmap walking code has been 
> retained but turned into a verification mechanism that is enabled using 
> -XX:+UnlockDiagnosticVMOption -XX:+VerifyDuringGC.
>
> Testing: GC test suite with a low marking threshold (10%); OpenDS, 
> KitchenSink, and jprt with the additional verification code enabled.
>
> JohnC
>
>
>
>
>   




More information about the hotspot-gc-dev mailing list