JDK-8166995 : Consider removing stale cards from HCC during cleanup
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2016-09-30
  • Updated: 2017-01-18
  • Resolved: 2016-10-24
Related Reports
Relates :  
Relates :  
Description
Some of the complexity in refine_card / oops_on_card_seq_iterate_careful arises from the possibility of "stale" marked cards, especially during concurrent refinement.  These are cards in regions that have been freed and then possibly reallocated.  At present the only source of stale cards in the concurrent case seems to be HCC eviction.  (Eager reclaim of humongous objects flushes relevant remembered sets (possibly containing stale entries) for reconsideration during that GC, but in-GC card clipping to scan_top deals with that.)  Doing HCC cleanup when freeing regions might remove the need for klass_or_null checking in the humongous case for concurrent refinement.

Comments
It turns out there are other sources of stale cards being fed into refine_card, and they aren't likely to go away. Hence the motivation for cleaning up HCC no longer exists. If some other reason is found later, a new bug can be filed.
24-10-2016

Doing klass_or_null checking (even with the acquire barrier) in the concurrent case may still be preferable to HCC cleanup if the latter needs to be done in a STW pause. Eliminating the klass_or_null check in the non-concurrent case is covered by JDK-8071280.
30-09-2016