JDK-2127742 : CMS: more helpful message for concurrent mode failures
  • Type: Backport
  • Backport of: JDK-6214543
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2005-06-30
  • Updated: 2010-12-08
  • Resolved: 2005-08-11
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 JDK 6
5.0u5 b03Fixed 6Fixed
Description
See parent CR.
###@###.### 2005-07-11 19:35:52 GMT
Comments
SUGGESTED FIX Event: putback-to Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/1.5/tiger_update5_baseline (jano.sfbay:/export/disk05/hotspot/ws/1.5/tiger_update5_baseline) Child workspace: /net/prt-web.sfbay/prt-workspaces/20050701224437.ysr.tiger_update/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20050701224437.ysr.tiger_update/workspace) User: ysr Comment: --------------------------------------------------------- Original workspace: neeraja:/net/spot/scratch/ysr/tiger_update Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/1.5/tiger_update5_baseline/2005/20050701224437.ysr.tiger_update/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/1.5/tiger_update5_baseline/2005/20050701224437.ysr.tiger_update/workspace/webrevs/webrev-2005.07.02/index.html Fixed 6214543: CMS: more helpful message for concurrent mode failure (subCR: 2127742) Fixed 6250214: CMS: perm gen expansion without explicit GC, but with concurrent cycle initiation (subCR: 2127741) Webrev: http://analemma.sfbay/net/spot/scratch/ysr/tiger_update/webrev.html Verbatim backport to TU5 of the changes in mustang. Below are the original putback messages; the same testing was replayed for the Tiger backport as well. Reviewed by: John Coomes, Peter Kessler Approved for 5.0u5 b03 by: J2SE Update Release Core Team ------------- 6214543: CMS: more helpful message for concurrent mode failure [If you happen to look at the bug report, this started out as an investigation of conc mode failures at a customer site in Singapore, but that issue was resolved as the customer had overlooked switching on class unloading with CMS. The customer-facing engineer however wanted the concurrent mode failure messages to be more explicit. A fortnight ago, a similar request came in from Nortel, which is the second SR in this CR.] We declare "(concurrent mode failure)" whenever an ongoing CMS collection is interrupted by an explicit GC request or, irrespective of an ongoing CMS cycle, the VM needed to bail into a stop-world collection of the CMS heap. For the case where we collect because of explicit user request but do not interrupt an ongoing concurrent cycle, we do not print a message declaring concurrent mode failure. The final form of the code gained from a simplification suggested by Jon. Fix verified: yes Verification testing: run with CMS and artificially small heap to induce frequent concurrent mode failures; note that explicit requests do not print the message unless they collide with an ongoing concurrent collection. Also tested with -XX:+ExplicitGCInvokesConcurrent and with CMSInitiatingOccupancyFraction=100 UseCMSInitiatingOccupancyOnly ---------------------------------------------------------- 6250214: CMS: perm gen expansion eithout explicit GC, but with concurrent cycle initiation The mem_allocate() method of perm gen would force a stop-world GC when expanding perm space every MaxPermHeapExpansion bytes. This is a fine policy for the stop-world collectors, but blows pause times for the CMS collector. We now avoid a full stop-world GC in the case of CMS unless we have reached the limit and the allocation has failed. Existing CMS triggering policy would (as Jon pointed out) then start a CMS cycle at the next scavenge following the perm gen expansion. Since one expects allocation rates in the young gen to be much larger than in perm gen, this synchronous sampling based policy for initiating CMS collection appears to suffice for the moment, rather than asynchronously triggering the CMS cycle upon the perm gen expansion event. In a separate bug, i'll consider restructuring some of this code so as to avoid the repeated lock/unlock of the free list lock in the work loop. Fix Verified: yes Verification Testing: spec+CMS with +DisableExplicitGC PermSize=1M MaxPermHeapExpansion=4K and noted that perm gen expands without initiating a stop-world GC. Other testing: PRT, refworkload ------------- Files: update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/permGen.cpp update: src/share/vm/runtime/concurrentMarkSweepThread.hpp Examined files: 3205 Contents Summary: 3 update 3202 no action (unchanged) ###@###.### 2005-07-11 19:35:52 GMT
11-07-2005
WORK AROUND see parent CR. ###@###.### 2005-07-11 19:35:53 GMT
11-07-2005
EVALUATION Fixed in TU5 b03. ###@###.### 2005-07-11 19:35:52 GMT
11-07-2005