United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6369448 : Unnecessary FullGC

Details
Type:
Bug
Submit Date:
2006-01-06
Status:
Resolved
Updated Date:
2010-12-03
Project Name:
JDK
Resolved Date:
2006-01-31
Component:
hotspot
OS:
generic,windows_xp
Sub-Component:
gc
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u4,6
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

Description
Unnecessary FullGC seems to run.

REPRODUCING and BEHAVIOR:
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
   NOTE:
      -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
@133796]

----- Copy -----
sun.management.GarbageCollectorImpl@82c01f
GarbageCollectorMXBean.getName():Copy
GarbageCollectorMXBean.getCollectionCount():100
GarbageCollectorMXBean.getCollectionTime():1962
------------------------------------

----- MarkSweepCompact -----
sun.management.GarbageCollectorImpl@133796
GarbageCollectorMXBean.getName():MarkSweepCompact
GarbageCollectorMXBean.getCollectionCount():0
GarbageCollectorMXBean.getCollectionTime():0
------------------------------------

INVESTIGATION:
  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.

EXPECTED BEHAVIOR:
 ....
 [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.

                                    

Comments
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)
                                     
2006-01-27
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))
                                     
2006-01-24
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.)
                                     
2006-01-12



Hardware and Software, Engineered to Work Together