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.
Regards,
JohnC
More information about the hotspot-gc-dev
mailing list