JDK-8069330 : Adjustment of concurrent refinement thresholds does not take hot card cache into account
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-01-20
  • Updated: 2018-06-21
  • Resolved: 2015-10-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b89Fixed
Related Reports
Duplicate :  
JDK-8135062 - Hot Card Cache Scan time intermixed with costs per card during update RS for GC base time prediction
Relates :  
JDK-8137022 - Concurrent refinement thread adjustment and (de-)activation suboptimal
Description
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)