JDK-6446077 : Long GC times after Concurrent Mode Failure
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: x86
  • Submitted: 2006-07-04
  • Updated: 2011-02-16
  • Resolved: 2006-09-13
Related Reports
Duplicate :  
JDK-6459113 - CMS+ParNew: wildly different ParNew pause times depending on heap shape caused by allocation spread
Relates :  
JDK-6433335 - ParNewGC times spiking, eventually taking up 20 out of every 30 seconds
Description
Customer complains of poor performance after encountering "concurrent mode failure".  For 1.4.2_x, its a one time hit and it performs normally.  For 5.0, subsequent collections are slow.
Comments
EVALUATION As explained in the comments section, this bug should be closed as a duplicate of 6459113, transferring the escalation to that bug so as to backport the fix to approrpiate update releases. SubCR's of 6459113 have already been created for the relevant update releases.
13-09-2006
EVALUATION With an instrumented build, found that after 'concurrent mode failure', ParNew GC is spending long times in block_start() calls. The reason could be that after a Full GC, large free blocks might be appearing in CMS heap and due to those large free blocks, traversing the block offset table to find the start of blocks is taking time. I changed N_powers from 3 to 51 (suggested by Ramki for an issue from GD) to optimize the computation of logarithmic backskip while finding the start of object. The provided testcase with this fix showed significant improvement; there were no long pauses after 'concurrent mode failure'. I have given the fixed binary to customer for testing.
05-07-2006