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

[Bengt Rutisson]

John,

Thanks for the explanation and for confirming my thoughts.

I agree that your current solution is more robust for future code changes. 

Bengt

15 dec 2011 kl. 18:50 skrev John Cuthbertson <john.cuthbertson at oracle.com>:

> Hi Bengt,
> 
> On 12/15/11 00:24, Bengt Rutisson wrote:
>> 
>> 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
> 
> Changing the interface to use a "trusted" flag would have worked and you would not have needed to the per-worker time stamp. I initially thought about something similar (and much simpler) i.e. assuming that the entries would be valid post-RSet scanning. I did not, however, want to introduce a hard dependency between distinct phases of the pause. With the the "trusted" flag, the dependency is mostly eliminated (you could always pass false), but that defeats the purpose of caching the starting values.  Also, as programmer, you would need to cognizant about when to trust the entries and when not to. Get it wrong (i.e. pass true before the entries can actually be trusted) and disaster will ensue. Unless you reduce the risk and take it out of the programmer's hands by using a global "trusted" flag which itself is set to "not-trust" at the start or end of the pause. As you said, though, we lose a little bit of flexibility.
> 
> Regards,
> 
> JohnC