EVALUATION

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

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)
                                     

SUGGESTED FIX

Please see http://analemma.sfbay/net/spot/scratch/ysr/MT/webrev.
                                     

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>
                                     

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.
                                     

EVALUATION

See comments abd description sections. This should be fixed in
Mustang (and backported to 1.5 and 1.4.2 update trains).