United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6541037 Ability to unload classes upon an explicit concurrent gc request
JDK-6541037 : Ability to unload classes upon an explicit concurrent gc request

Details
Type:
Enhancement
Submit Date:
2007-03-30
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2007-05-24
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
hs10 (b13)

Related Reports
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
As in synopsis; see comments section for discussion.

                                    

Comments
SUGGESTED FIX

The following is subject to code-review:

    http://analemma.sfbay/net/spot/scratch/ysr/unload/webrev
                                     
2007-03-30
EVALUATION

A new experimental JVM has been implemented for testing by customer;
once we are satisfied that there are no hidden land-mines
(based both on customer input and experience, as well as internal
review and analysis by team members) this RFE will be brought
before the CCC for fast-track approval.
                                     
2007-03-30
SUGGESTED FIX

<deleted>
                                     
2007-04-05
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/20070502110909.ysr.unload/workspace
                  (prt-web:/net/prt-web.sfbay/prt-workspaces/20070502110909.ysr.unload/workspace)
User:             ysr

Comment:

---------------------------------------------------------

Job ID:                 20070502110909.ysr.unload
Original workspace:     neeraja:/net/spot/scratch/ysr/unload
Submitter:              ysr
Archived data:          /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2007/20070502110909.ysr.unload/
Webrev:                 http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2007/20070502110909.ysr.unload/workspace/webrevs/webrev-2007.05.02/index.html

Fixed 6541037: Ability to unload classes upon an explicit concurrent gc request

   webrev: http://analemma.sfbay/net/spot/scratch/ysr/unload/webrev

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
resulting performance. 

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
Verification testing: 
  (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

Files:
update: src/share/vm/memory/compactibleFreeListSpace.cpp
update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp
update: src/share/vm/memory/concurrentMarkSweepGeneration.hpp
update: src/share/vm/memory/concurrentMarkSweepGeneration.inline.hpp
update: src/share/vm/memory/genOopClosures.hpp
update: src/share/vm/runtime/arguments.cpp
update: src/share/vm/runtime/globals.hpp

Examined files: 3961

Contents Summary:
       7   update
    3954   no action (unchanged)
                                     
2007-05-02
EVALUATION

A new JVM-specific flag:
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses.
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,
schedulable, basis.


===============
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses:
 
  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.
===============
                                     
2007-10-08



Hardware and Software, Engineered to Work Together