RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse

Tony Printezis tony.printezis at oracle.com
Thu Dec 15 17:59:18 UTC 2011


Bengt,

Your idea will definitely work. To add to what John said in his 
follow-up e-mail: it would have been easy to validate the use of the 
use_cached_value parameter by NULLing the per-worker entries between GCs 
in non-product builds. So, if use_cached_value == true, entry is NULL, 
and CSet head is not NULL, you know the use_cached_value is wrong. But, 
I like John's approach. It's a bit more flexible and more easily re-usable.

Tony

Bengt Rutisson wrote:
>
> John and Tony,
>
> Thanks for the explanations about the need for individual timestamps 
> for the worker threads. A followup question below to make sure that I 
> understand this correctly.
>
>> As Tony points out - an individual TS per worker is needed to avoid 
>> clearing the array containing the starting regions during evacuation 
>> pauses.
>>
>>>> Do all worker not participate in RSet scanning before they go on to 
>>>> do complete_marking_in_collection_set() ?
>>
>> Currently yes. But that may not always be the case and expanding the 
>> code to handle differing numbers of threads should be straight forward.
>
> So, in the current implementation it would be possible to change the 
> interface for start_cset_region_for_worker() to be something like:
>
> HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int 
> worker_i, bool use_cached_values)
>
> RSet scanning would pass use_cached_values=false, while the other uses 
> would pass use_cached_values =true. And instead of looking at the 
> timestamp to decide if we can trust the cached values we would look at 
> use_cached_values. If use_cached_values == false we would not use the 
> cached values, but when we have calculated a new value we would update 
> the cache. Would that work? I am not saying it is a better 
> alternative, I just want to make sure I understand the code paths here.
>
> (Of course with this approach you would not be able to do the latest 
> optimization that you implemented - to look for the previous thread's 
> cached value to see if you can use that as a starting point.)
>
> Bengt



More information about the hotspot-gc-dev mailing list