Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline
Child workspace: /net/prt-web.sfbay/prt-workspaces/20050913230606.ysr.MT/workspace
Original workspace: karachi:/net/spot/scratch/ysr/MT
Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050913230606.ysr.MT/
Fixed 6319671: CMS should use Heap_lock for protecting heap resizing, instead of CMS token
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
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
Examined files: 3693
3691 no action (unchanged)
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.