JDK-6896603 : CMS/GCH: incremental_collection_will_fail() should use more current data
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs19,6,6u4
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2009-10-30
  • Updated: 2011-04-20
  • Resolved: 2011-04-20
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 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Duplicate :  
JDK-6990095 - Deprecate and eliminate -XX:-HandlePromotionFailure
Duplicate :  
JDK-6261660 - CMS promotion failure & gc_locker induced GC malinteraction
Relates :  
JDK-6995045 - assert(!gch->incremental_collection_failed()) failed: Error, defNewGeneration.cpp:827
Description
This can result in unnecessarily pessimistic initial bailout to a
full collection (concurrent mode failure) when a scavenge would in fact
have provably succeeded at the point at which the decision to bail out was made.
See related email in comments section.
Synopsis changed from:-

   CMS/GCH: collection_attempt_is_safe() ergo should use more recent data

to:-

   CMS/GCH: incremental_collection_will_fail() should use more current data
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a7214d79fcf1
04-12-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a7214d79fcf1
25-10-2010
SUGGESTED FIX Preliminary webrev, still under test:- http://javaweb.sfbay.sun.com/~ysr/neeraja/export/ysr/cms_bail/webrev/
11-10-2010
SUGGESTED FIX Too late for hs19 now, but definitely fix for hs20.
20-08-2010
WORK AROUND -XX:MaxLiveObjectEvacuationRatio=0 Note, however, that this forces a scavenge attempt even when it is provably doomed to promotion failure. The attendant cost of "unwinding" a partially-completed scavenge before a full gc can be done might be somewhat high and should be considered when attempting this workaround. The situation in which this bug manifests is however almost always a case where a larger old gen, allowing for more scavenges per CMS cycle, would have allowed us to avoid the bug entirely (i think).
30-10-2009
SUGGESTED FIX Adjust the logic in incremental_collection_will_fail() so as to use more up-to-date information about available free space.
30-10-2009
EVALUATION Flaw in ergo bailout logic revealed from rare deployment corner case. Probably quite easy fix.
30-10-2009