At the end of collection the concurrent refinement thresholds are adjusted according to the recently processed number of buffers to make sure that in the next collection the gc can keep up with the allocated time for the Update RS phase.

However, this does not take the other part of the update rs phase, draining the hot card cache into account. (See G1CollectoryPolicy::adjust_concurrent_refinement()).

The hot card cache may contribute significantly to update RS time, containing 2^G1ConcRSLogCacheSize entries (10 by default). Since they also need to processed, and this may be a considerable amount, they may need to be taken into account here.

(The 2^10 entries correspond to "only" four full DCQ buffers, but they are almost guaranteed to be full, and not containing duplicates, so they may actually be more work than corresponding DCQ entry buffers)