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