JDK-8153170 : Card Live Data does not correctly handle eager reclaim
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-31
  • Updated: 2018-06-21
  • Resolved: 2016-04-19
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 b120Fixed
Related Reports
Blocks :  
JDK-8151386 - Extract card live data out of G1ConcurrentMark
Relates :  
JDK-8156926 - Card live data for reused old region is wrong
Relates :  
JDK-8027959 - Early reclamation of large objects in G1
Description
Between the remark and cleanup pauses card live data is created based off recent marking.

During that phase regions might be reclaimed (e.g. eager reclaim), so the card live data at the end is not up to date wrt to that. The card live data contains too many bits for these regions.

Make sure that card live data is completely correct and also tighten the verification accordingly.
Comments
This is not an integration blocker, this is a day one "bug" related to in eager reclaim.
13-04-2016
The impact of having too many areas as "live" is a benign minor performance degradation. That's why my suggestion as P4.
31-03-2016
noreg-other: the code already contains self-verification.
31-03-2016