• Type: Enhancement
• Component: hotspot
• Sub-Component: gc
• Affected Version: 6

• Priority: P4
• Status: Resolved
• Resolution: Fixed
• OS: generic
• CPU: generic

• Submitted: 2007-03-30
• Updated: 2017-05-16
• Resolved: 2007-05-24

JDK 6	JDK 7	Other
6u4Fixed	7Fixed	hs10Fixed

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. =============== 08-10-2007 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) 02-05-2007 SUGGESTED FIX <deleted> 05-04-2007 SUGGESTED FIX The following is subject to code-review: http://analemma.sfbay/net/spot/scratch/ysr/unload/webrev 30-03-2007 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. 30-03-2007