JDK-8135062 : Hot Card Cache Scan time intermixed with costs per card during update RS for GC base time prediction
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-09-04
  • Updated: 2015-10-15
  • Resolved: 2015-10-15
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
9Resolved
Related Reports
Duplicate :  
Description
The hot card cache scan time is intermixed with the flushing of the refinement buffer, i.e. Update RS time. If the hot card cache is large, this makes the prediction of the costs per card very wrong.

Since costs per card is used for determining update RS time, i.e. the base time for the evacuation, this makes this prediction very wrong.

I.e. we do:

base time = predicted update RS time + ....

predicted update RS time = cost-per-pending-cards * amount-of-pending-cards

cost-per-pending-cards = integrate (update rs time / number of processed cards)

The problem is that update RS time is not just the time it takes to process the number of cards in the current refinement buffers, but includes (constant) HCC scan time. If the latter is large, the cost-per-pending-cards is actually very much overestimated.

I.e. update RS time != number of processed cards * time per card , but number of processed cards * time per card + (constant) HCC scan time

The problem is, if the base time is mispredicted (too large), the predictions are way off.

Comments
ILW - M (bad data in G1 pause time math) M (app dependent) H (none) -> P3
04-09-2015