JDK-6319671 : CMS should use Heap_lock for protecting heap resizing, instead of CMS token
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris
  • CPU: generic,sparc
  • Submitted: 2005-09-02
  • Updated: 2010-04-02
  • Resolved: 2005-09-22
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
6 b53Fixed
Related Reports
Relates :  
JDK-6316605 - atg server crashed with CMS collector
Relates :  
JDK-6263371 - SEGV in MarkFromRootsClosure::scanOopsInOop
Relates :  
JDK-6325682 - VM lockup with -XX:+UseConcMarkSweepGC while loading classes with custom classloader
Relates :  
JDK-6319688 - Incorrect locking in CMSPermGen::mem_allocate()
Description
See 6316605 for releated discussion. CMS currently uses the
CMS token to coordinate heap resizing. For the sake of
uniformity wrt the rest of GC, it should try and replace
that use with that of the Heap_lock. This needs some
investigation as the resulting code may cause a small
performance impact and a larger code complexity impact.
The assumption, in 6316605, that the CMS token is an authoritative
proxy for the Heap_lock for the purposes of expanding the heap
turned out to be incorrect, and was flagged as an assertion failure
while expanding the heap by a mutator thread that ran out of space
in the perm gen. Recall that, for pause-time policy reasons, CMS
allows the mutator threads to expand the perm gen without reaching
a safepoint. The idea is that the Heap_lock protects such expansion.
Clearly, the CMS thread must follow the same protocol.

We are therefore converting what had originally been a clean-up RFE
targeted for Dolphin into a P2 bug-fix targeted for Mustang.
Comments
EVALUATION This bug has been fixed in Tiger U7b01 as well, as a result of the fixes needed for 6319688.
03-01-2006
SUGGESTED FIX Event: putback-to Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline (jano.sfbay:/export/disk05/hotspot/ws/main/gc_baseline) Child workspace: /net/prt-web.sfbay/prt-workspaces/20050913230606.ysr.MT/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20050913230606.ysr.MT/workspace) User: ysr Comment: --------------------------------------------------------- Original workspace: karachi:/net/spot/scratch/ysr/MT Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050913230606.ysr.MT/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050913230606.ysr.MT/workspace/webrevs/webrev-2005.09.14/index.html Fixed 6319671: CMS should use Heap_lock for protecting heap resizing, instead of CMS token http://analemma.sfbay/net/spot/scratch/ysr/MT/webrev In a previous putback we had promised to: ... change CMS so that the use of the CMS token proxy is eliminated (if it's possible to do so without any increase in code complexity or degradation in performance) for the pruposes of heap resizing (this would have the beneficial effect of using the same mechanism across all heap configurations). This putback implements that change. Indeed, nightly testing showed an important case, which our manual code inspection had missed, where the CMS token is, in fact. not an effective substitute for the Heap-lock for protecting heap resizing. Recall that, in CMS, mutators may expand the perm gen without precipitating a full stop-world GC. Mutators also (currently) never acquire the CMS token. We can then end up in a situiation where a mutator and the concurrent CMS thread are concurrently trying to resize the perm gen. By using the Heap_lock uniformly to protect all heap resizing in CMS, we eliminate said race. As promised in a previous putback, a future putback will eliminate the obsolete ExpandHeap_lock from elsewhere in the JVM as well. Reviewed by: Jon Masamitsu Fix Verified: yes Verification Testing: RT_QUICK and RT_PLUMHALL with CMS Other testing: prt, refworkload Files: update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/concurrentMarkSweepGeneration.hpp Examined files: 3693 Contents Summary: 2 update 3691 no action (unchanged)
14-09-2005
SUGGESTED FIX Please see http://analemma.sfbay/net/spot/scratch/ysr/MT/webrev.
12-09-2005
SUGGESTED FIX Add a new abstract state to the CMS control automaton. Heap resizing by CMS thread happens in this state only and the CMS thread takes the Heap_lock before entering this state and, as usual, offering to yield the baton before entering this state. [If the baton is passed in this state, the foreground thread may resize the heap, and reset the state of the CMS control automaton to "Reset".] All heap resizing assertions that use have_cms_token() now assert that the Heap_lock is suitably held by the executing thread or on its behalf by a proxy thread.
09-09-2005
WORK AROUND Fix the size of the heap thus obviating the need to resize it: -Xms<n> -Xmx<n> -XX:PermSize=<m> -XX:MaxPermSize=<m>
09-09-2005
EVALUATION See comments abd description sections. This should be fixed in Mustang (and backported to 1.5 and 1.4.2 update trains).
02-09-2005