JDK-8225418 : G1: region attribute remembered set state disagrees with actual remembered set state
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-06-06
  • Updated: 2019-08-08
  • Resolved: 2019-06-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 13 JDK 14
13 b25Fixed 14Fixed
Related Reports
Relates :  
JDK-8218668 - Clean up evacuation of optional collection set
Relates :  
JDK-8200545 - Improve filter for enqueued deferred cards
Description
Sporadically failing assertion was observed on PPC64 and x86_64: 
assert(region_attr.needs_remset_update() == hr_obj->rem_set()->is_tracked()) failed: State flag indicating remset tracking disagrees (false) with actual remembered set (true) for region 62 
with region: 
| 62|0x00000000f3e00000, 0x00000000f3f00000, 0x00000000f3f00000|100%| O| |TAMS 0x00000000f3f00000, 0x00000000f3e00000| Complete 

The assertion was introduced by JDK-8200545, but this behavior may be older. 

Failing test on x86: 
jck: api/java_text/NumberFormat/UnicodeExtensions 
ran with -Xcomp -XX:-TieredCompilation and -Xms128m -Xmx288m.
Comments
noreg-hard justification: with a changing hardware and environment in the CI it is practically impossible to write a reproducer because the following needs to line up: - need mixed collections - needs optional collection set regions - need an collection set increment that is not used - need j.l.ref.References in the young gen that are kept alive during GC - these j.l.ref.References need to reference an object in old gen that a) has a remembered set and b) is not part of the collection set Most of these steps are dependent on timing including available CPU time. However the change adds internal verification that asserts on some tier1 tests.
07-06-2019
In G1CollectionSet::abandon_optional_collection_set() we completely reset the region attribute for those unused old regions, clearing both the "type" and the "needs_remset_update" field to default values regardless of whether we actually need to maintain their remembered sets or not. However, the next GC phases that copy data (i.e. reference processing) need the "needs_remset_update" field of the heap region attributes to be correct - and the assert correctly notes that mismatch. I.e. the fix is to keep the "needs_remset_update" value for abandoned collection set regions as it was before.
06-06-2019
Two additional reproductions in random tests (jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java (May 31st)/ java/lang/System/LoggerFinder/internal/BootstrapLogger/BootsTrapLoggerTest.java (Jun 3rd)) our CI, on OSX x64 only. Attempts to reproduce failed. All of these have in common - the region X where the check fails is random (but these are all different applications) - they are noticed when iterating over an object in an old evacuation region referencing that region X outside of the collection set - the pTAMS of these regions X is at the end of the region, indicating that this region has existed *before* the GC (presumably with the "Complete" remset state) - all of these failures occur during reference processing per stack trace - almost all cases were reproduced with -Xcomp - in the core dumps we have the region attribute table contents correspond to the assertion failure (e.g. may not have been the case if this is a memory visibility issue) - surrounding region attributes look okay.
06-06-2019