JDK-7098512 : G1: Do not clear the next marking bitmap at the start of a Full GC
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2011-10-06
  • Updated: 2022-07-01
  • Resolved: 2022-07-01
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8210708 - Use single mark bitmap in G1
Relates :  
JDK-8048085 - Aborting marking just before remark results in useless additional clearing of the next mark bitmap
Description
At the start of a Full GC we call ConcurrentMark::abort() to notify the concurrent marking operation that might be in progress to stop what it's doing. CM::abort() clears the next marking bitmap:

// abandon current marking iteration due to a Full GC
void ConcurrentMark::abort() {
  // Clear all marks to force marking thread to do nothing
  _nextMarkBitMap->clearAll();
  ...
}

This is not really necessary, at least not because of the explanation in the method. The CM workers should have yielded before the Full GC safepoint could start, therefore they will not observe that the bitmap was cleared.

Having said that, not doing the clearing does introduce infrequent failures during the first GC pause after a Full GC that aborts a CM cycle. So, we should first get to the bottom of why this is. But, it will be good to avoid the bitmap clearing at the start of the Full GC and let the CM thread do it concurrently.
Comments
With JDK-8210708 there is no "next" bitmap any more and bitmap clearing must be handled differently anyway.
01-07-2022
Note that the attached patch seems to fine after testing on a few tests that stress conc marking failure handling and other testing; the spurious failures reported in this CR may be caused by bugs already fixed.
10-07-2014
Attached a patch that implements the suggestion. After JDK-8038423 this patch needs major adaptation. In particular, after JDK-8038423 it is possible that full gc interrupts the concurrent bitmap clearing itself and during that full gc heap sizing may uncommit some regions. So iteration over the heap (during concurrent bitmap clear) would need to be restarted from scratch to make sure the mark bitmap of all heap regions are cleared (and the concurrent bitmap clear does not accidentally touch mark bitmaps for regions just decommitted) If the full gc took care of clearing the mark bitmap then a simple abort of the complete concurrent bitmap clear would be sufficient.
10-07-2014