RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse
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
>>> 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,
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