RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse
Tony Printezis
tony.printezis at oracle.com
Tue Dec 13 16:00:47 UTC 2011
Bengt Rutisson wrote:
>
> Hi John,
>
> First a high level question: I think your changes are correct, but
> this got a bit more complex than I thought it would be when I
> suggested it in the review of 7112743. Is the extra complexity worth
> the benefits of only having to do the iterations once instead of twice?
(Small correction: once instead of three times). The thought had also
crossed my mind. Maybe on some machines with not great single-threaded
performance it will be worth it.
> I don't have a clear answer to this myself, I just wanted to bring the
> question up. Clearly it is more efficient, but it is 3x as much code
> to do the same thing.
>
> One detail for my understanding: why do we need separate time stamps
> for each worker?
Each worker independently needs to know whether its starting region is
valid or not. If John didn't have a timestamp per worker, he'd need to
reset the table at the start or end of each GC.
Tony
> Do all worker not participate in RSet scanning before they go on to do
> complete_marking_in_collection_set() ?
>
> Bengt
>
>
> On 2011-12-09 20:18, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers to review the changes for this CR?
>> The webrev can be found at:
>> http://cr.openjdk.java.net/~johnc/7119908/webrev.0/
>>
>> Summary:
>> As part of the code review comments for 7112743 (G1: Reduce overhead
>> of marking closure during evacuation pauses) it was suggested that
>> instead of recalculating the starting heap region for each worker
>> thread, we reuse the values calculated during RSet scanning. These
>> changes address that review comment. In these changes I maintain a
>> cache that is used and updated by
>> G1CollectedHeap::start_cset_region_for_worker(). The first time this
>> routine is called by a worker thread during an evacuation pause
>> (currently during RSet scanning) the cached value for the worker gets
>> set; when the routine is called subsequently the region that was
>> cached for the worker is returned. I employ a simple stamp mechanism
>> based upon the number of GCs that ensures the validity of the regions
>> in the cache and makes clearing the cache unnecessary.
>>
>> Testing:
>> GC Test suite with a small marking threshold (10%) with and without
>> verification; the configuration of SPECjbb used to test 7117423;
>> Kitchensink.
>>
>> Thanks,
>>
>> JohnC
>>
>
More information about the hotspot-gc-dev
mailing list