JDK-6369448 : Unnecessary FullGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u4,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2006-01-06
  • Updated: 2010-12-03
  • Resolved: 2006-01-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_13Fixed 6 b70Fixed
Unnecessary FullGC seems to run.

The attached test progtam, GCBeanTEST.java tries to allocate 4M memory 100 times.

1) Compile the test program and invoke the following command line.
   java -Xms64m -XX:+UseSerialGC -XX:NewRatio=12 -verbose:gc GCBeanTEST
      -XX:+UseSerialGC and -XX:NewRatio=12 is added to avoid that runtime system 
      considers the PC as "server" machine.(to avoid auto-configuration)

The following message will appear

K:\shares2\gc>java -Xms64m -XX:+UseSerialGC -XX:NewRato=12 -verbose:gc GCBeanTEST
[GC 285K->133K(65088K), 0.0046967 secs]
[Full GC 133K->133K(65088K), 0.0156947 secs]
[GC 4229K->4229K(65088K), 0.0006263 secs]
[Full GC 4229K->133K(65088K), 0.0160146 secs]
[GC 4229K->4229K(65088K), 0.0004048 secs]
[Full GC 4229K->133K(65088K), 0.0281636 secs]
[GC 4229K->4229K(65088K), 0.0003623 secs]
[Full GC 4229K->133K(65088K), 0.0186784 secs]
[GC 4229K->4229K(65088K), 0.0003084 secs]
[Full GC 4229K->133K(65088K), 0.0153316 secs]
sun.management.GarbageCollectorImpl@82c01f, sun.management.GarbageCollectorImp

----- Copy -----

----- MarkSweepCompact -----

  The messages by -verbose:gc 
 [GC 4229K->4229K(65088K), 0.0003084 secs]
 [Full GC 4229K->133K(65088K), 0.0153316 secs]
  says GC anf Full GC occurs 100 times respectively.
  CopyGC and FullGC seems to occur per one allocation. 
  The following scenario seems to happen.
  1) The runtime system tries to allocate object to Eden, but fails because allocation size
     is bigger than Eden Size.
  2) The runtime system tries to copy GC, but fails.
  3) FullGC runs and allocate the object to tenured area.

 [GC 4229K->4229K(65088K), 0.0003084 secs]
 [Full GC 4229K->133K(65088K), 0.0153316 secs]
 The above listed FullGC seems unnecessary.
 Such FullGC is hoped not to run.

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/20060126152955.ysr.policy/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20060126152955.ysr.policy/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20060126152955.ysr.policy Original workspace: neeraja:/net/spot/scratch/ysr/policy Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060126152955.ysr.policy/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060126152955.ysr.policy/workspace/webrevs/webrev-2006.01.26/index.html Fixed 6369448: Unnecessary FullGC seems to run in 6.0b65 Fixed 4855795: Spurious OutOfMemoryError exceptions Webrev: http://analemma.sfbay/net/spot/scratch/ysr/policy/webrev The problem in 6369448 was that the policy for deciding whether it was possible to allocate an object in the young gen was based on the maximum potential size of young gen (not even Eden) while there was nothing in the resizing policy that was affected by the failure to accomodate such requests. The correct thing, under the circumstances, is to recognize that Eden cannot allocate objects larger than its _current_ size, and allow an older generation to satisfy such an allocation request if possible. This is a day-one bug in the policy object. The problem in 4855795 was identified by Peter, as described in the bug report. We now allow the VM thread to allocate out of from space when space is tight. This prevents the "unexpected" out of memory error described. Piggyback: recent testing with -XX:+CMSMarkStackOverflowALot revealed some obsolete non-product code had been left around. The lock in question had been removed sometime ago, but not all of its uses had been removed. Some (related) documentation comments were also fixed. Reviewed by: Jon Masamitsu, John Coomes Approved (low risk) by: Dave Cox Fix Verified: yes Verification Testing: 6369448 test in bug report 4855795 test in bug report Other testing: specjvm, PRT refworkload (performance) with CMS, Serial. Files: update: src/share/vm/memory/collectorPolicy.cpp update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/defNewGeneration.cpp Examined files: 3768 Contents Summary: 3 update 3765 no action (unchanged)

SUGGESTED FIX ------- collectorPolicy.cpp ------- 425c425 < // . the allocation won't fit into the maximum young gen heap --- > // . the allocation won't fit into the current young gen heap 434c434,435 < return (word_size > heap_word_size(_max_gen0_size)) --- > size_t gen0_capacity = gch->get_gen(0)->capacity_before_gc(); > return (word_size > heap_word_size(gen0_capacity))

EVALUATION Poor collector policy for escalating allocation to older generation. (ignore previous note that was in this space; this is a day-one bug; we need to revisit and fix the policy.)