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

John Cuthbertson john.cuthbertson at oracle.com
Thu Dec 15 17:50:51 UTC 2011

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.



More information about the hotspot-gc-dev mailing list