United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6319671 CMS should use Heap_lock for protecting heap resizing, instead of CMS token
JDK-6319671 : CMS should use Heap_lock for protecting heap resizing, instead of CMS token

Details
Type:
Bug
Submit Date:
2005-09-02
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2005-09-22
Component:
hotspot
OS:
solaris,generic
Sub-Component:
gc
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

See comments abd description sections. This should be fixed in
Mustang (and backported to 1.5 and 1.4.2 update trains).
                                     
2005-09-02
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>
                                     
2005-09-09
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.
                                     
2005-09-09
SUGGESTED FIX

Please see http://analemma.sfbay/net/spot/scratch/ysr/MT/webrev.
                                     
2005-09-12
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)
                                     
2005-09-14
EVALUATION

This bug has been fixed in Tiger U7b01 as well, as a result of
the fixes needed for 6319688.
                                     
2006-01-03



Hardware and Software, Engineered to Work Together