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.
WORK AROUND
see parent CR
###@###.### 2005-07-11 19:37:47 GMT
11-07-2005
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:37:47 GMT
11-07-2005
EVALUATION
Fixed in TU5 b03.
###@###.### 2005-07-11 19:37:47 GMT