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

Bengt Rutisson bengt.rutisson at oracle.com
Thu Dec 15 08:24:21 UTC 2011

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.)


More information about the hotspot-gc-dev mailing list