Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline
Child workspace: /net/prt-web.sfbay/prt-workspaces/20070502110909.ysr.unload/workspace
Job ID: 20070502110909.ysr.unload
Original workspace: neeraja:/net/spot/scratch/ysr/unload
Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2007/20070502110909.ysr.unload/
Fixed 6541037: Ability to unload classes upon an explicit concurrent gc request
CMS does not currently (by default) unload classes during a concurrent
GC cycle, but rather only at a STW GC cycle. Class unloading requires
a special flag (+CMSClassUnloadingEnabled) which then allows perm
gen collection at each concurrent gc cycle. The choice of defaults was
made because of the significant impact of class unloading on the
CMS-remark phase. The idea was that the large majority of applications
out there that care about pause times do not do an unbounded amount of
allocation in the perm gen, so turning off class unloading would not
hurt most applications. Unfortunately, with the widespread use of class
loaders, reflection and string interning all of which cause allocation in the
perm gen, this assumption isn't as valid today.
In the current case, an ISV found that they did not want the impact of
pause times on class unloading at each GC cycle, yet wanted to be able
to unload classes opportunistically during periods when the impact of the
longer pauses would be minimal, i.e. they wanted the ability to schedule
unloading of classes. The expedient solution appears to be to allow
them this ability by calling an explicit System.gc() but with a new
flag enabled. This new flag, whose name is subject to change upon review,
has been tentatively called -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
in analogy to the existing flag -XX:+ExplicitGCInvokesConcurrent which
was introduced in 6.0 (also based upon a request from another telco ISV).
Note that (because of its name) the first flag above implies the second flag.
Either flag takes effect only in the presence of a concurrent collector such as
CMS today, and its replacement G1 tomorrow.
In the current case of CMS, we unload classes in a concurrent GC cycle
that was initiated in response to a concurrent explicit gc request.
The implementation takes care of the situation where heap verification
may be enabled, in which case the root sets and the deadness maps need
to be maintained correctly for the verification to work without problems.
In a hypothetcial future when CMS _does_ unload classes by default
setting the new flag will be essentially equivalent to setting
the existing flag +ExplicitGCInvokesConcurrent.
A prototype was tested by the ISV who appeared pleased with the
In parallel, we have begun work on ergonomically initiating concurrent
collection of the perm gen, so that the impact of class unloading
on remark pauses is kept to a minimum; see CR 6543076 for references
to this and related CR's.
Reviewed by: John Coomes, Igor Veresov
See also : http://ccc.sfbay/6541073
Fix verified: yes
(1) CMS w/ and w/o new flag, and w/ and w/o heap verification
(2) testing by ISV Natural Convergence (Thanks Ricardo Borba!)
Other testing: PRT, refworkload, runThese -quick w/CMS+new flag
Examined files: 3961
3954 no action (unchanged)
A new JVM-specific flag:
When enabled with the concurrent collector, this flag directs the JVM
to not only execute a concurrent colection cycle (as does the flag
-XX:+ExplicitGCInvokesConcurrent), but in addition
also unload classes in that collection cycle. This would allow the
application to recycle space in the perm gen on an as-required,
If this flag is set then, in response to an explicit GC request,
e.g. System.gc(), the JVM will run a concurrent collection cycle in which
classes eligible for collection are unloaded. This flag implies
-XX:+ExplicitGCInvokesConcurrent and, like that flag, is effective only
when a concurrent collector is in use.