JDK-8071913 : Filter out entries to free/uncommitted regions during iteration
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-01-29
  • Updated: 2018-11-06
  • Resolved: 2018-10-31
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 12
12 b18Fixed
Related Reports
Blocks :  
Blocks :  
Blocks :  
Relates :  
Description
The fix for JDK-8069034 introduced some filtering in the eager reclaim code path when iterating over the remembered sets of humongous objects to avoid marking cards in free regions dirty, which gives some assertions. This showed that the remembered sets may contain references to already freed regions (or otherwise known invalid areas), which are problematic in many ways:

 - we cannot uncommit the referenced regions because during remembered scanning we scan them
 - we scan areas that are known to not contain any reference, wasting time

The sources of such "invalid" entries are
  - the sparse remembered set particularly because it is not scrubbed during scrubbing
  - all remembered sets because we only scrub every now and then, but may free regions inbetween (e.g. eager reclaim, mixed gc)

A nicer way would be to eliminate these useless entries alltogether, some ideas in that direction

- improve scrubbing for the sparse remembered set
- filter out entries to currently free regions in the iterator
- remove entries (per-region remembered set) to freed regions as they are freed; one lazy way would be to count the number of times a region has been freed, during creation of the per-region remembered set store that value, and every time we iterate over them compare these values: if they match, iterate, otherwise reclaim (or start some process to reclaim that memory) etc.
Comments
Attached gc log showing the problem. The eden sizing has been modified to only base the eden size on the MMU.
07-04-2015

JDK-8069034 added some filter in the eager reclaiming mechanism to not mark cards in free regions, to avoid later assertion failures. Remove that check.
02-02-2015