Full GC runs even when enough space is remaining

I am running a server application with these specs:

OS: Solaris 9 32-bit

JVM: 1.4.2_11

Xms=Xmx=2048M

GC Settings:

-Xmn=256M

-XX:+UseParNewGC

-XX:+UseConcMarkSweepGC

-XX:PermSize=32M

-XX:MaxPermSize=128M

-XX:SurvivorRatio=8

-XX:MaxTenuringThreshold=36

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0

What I am seeing is Full GC runs 2-3 times even when sufficient tenured and young generation space is available and I don't understand why. Can someone please help?

2704.556: [CMS-concurrent-mark: 19.951/20.159 secs]

2704.556: [CMS-concurrent-preclean-start]

2705.262: [CMS-concurrent-preclean: 0.702/0.706 secs]

2705.263: [GC2705.263: [Rescan (parallel) , 0.2308587 secs]2705.494: [weak refs processing, 0.0025950 secs] [1 CMS-remark: 1297867K(1835008K)] 1323674K(2070976K), 0.2339031 secs]

2705.497: [CMS-concurrent-sweep-start]

2711.955: [Full GC {Heap before GC invocations=325:

Heap

par new generationtotal 235968K, used 88220K [0x70c00000, 0x80c00000, 0x80c00000)

eden space 209792K, 36% used [0x70c00000, 0x756d6c28, 0x7d8e0000)

from space 26176K, 44% used [0x7f270000, 0x7fdc0540, 0x80c00000)

tospace 26176K,0% used [0x7d8e0000, 0x7d8e0000, 0x7f270000)

concurrent mark-sweep generation total 1835008K, used 1297793K [0x80c00000, 0xf0c00000, 0xf0c00000)

concurrent-mark-sweep perm gen total 32768K, used 20306K [0xf0c00000, 0xf2c00000, 0xf8c00000)

2711.956: [ParNew: 88220K->15915K(235968K), 0.0430720 secs]2711.999: [CMS2713.816: [CMS-concurrent-sweep: 8.143/8.320 secs]

(concurrent mode failure)[Unloading class sun.reflect.GeneratedConstructorAccessor26]

[Unloading class sun.reflect.GeneratedConstructorAccessor46]

[Unloading class sun.reflect.GeneratedConstructorAccessor29]

[Unloading class sun.reflect.GeneratedConstructorAccessor30]

[Unloading class sun.reflect.GeneratedConstructorAccessor27]

[Unloading class sun.reflect.GeneratedConstructorAccessor52]

[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor1]

[Unloading class sun.reflect.GeneratedConstructorAccessor55]

[Unloading class sun.reflect.GeneratedConstructorAccessor56]

[Unloading class sun.reflect.GeneratedConstructorAccessor54]

[Unloading class sun.reflect.GeneratedConstructorAccessor51]

[Unloading class sun.reflect.GeneratedConstructorAccessor58]

[Unloading class sun.reflect.GeneratedConstructorAccessor42]

[Unloading class sun.reflect.GeneratedConstructorAccessor57]

[Unloading class sun.reflect.GeneratedConstructorAccessor41]

[Unloading class sun.reflect.GeneratedConstructorAccessor40]

[Unloading class sun.reflect.GeneratedConstructorAccessor25]

[Unloading class sun.reflect.GeneratedConstructorAccessor48]

[Unloading class sun.reflect.GeneratedConstructorAccessor21]

[Unloading class sun.reflect.GeneratedConstructorAccessor49]

[Unloading class sun.reflect.GeneratedConstructorAccessor47]

[Unloading class sun.reflect.GeneratedConstructorAccessor20]

[Unloading class sun.reflect.GeneratedConstructorAccessor50]

[Unloading class sun.reflect.GeneratedMethodAccessor6]

[Unloading class sun.reflect.GeneratedConstructorAccessor24]

[Unloading class sun.reflect.GeneratedConstructorAccessor28]

[Unloading class sun.reflect.GeneratedConstructorAccessor53]

[Unloading class sun.reflect.GeneratedMethodAccessor1]

: 1297793K->1313434K(1835008K), 44.4053374 secs] 1386013K->1313434K(2070976K), [CMS Perm : 20306K->20216K(32768K)] Heap after GC invocations=326:

Heap

par new generationtotal 235968K, used 0K [0x70c00000, 0x80c00000, 0x80c00000)

eden space 209792K,0% used [0x70c00000, 0x70c00000, 0x7d8e0000)

from space 26176K,0% used [0x7d8e0000, 0x7d8e0000, 0x7f270000)

tospace 26176K,0% used [0x7f270000, 0x7f270000, 0x80c00000)

concurrent mark-sweep generation total 1835008K, used 1313434K [0x80c00000, 0xf0c00000, 0xf0c00000)

concurrent-mark-sweep perm gen total 33696K, used 20216K [0xf0c00000, 0xf2ce8000, 0xf8c00000)

} , 44.4809014 secs]

2756.750: [GC [1 CMS-initial-mark: 1313434K(1835008K)] 1316446K(2070976K), 0.0188777 secs]

2756.769: [CMS-concurrent-mark-start]

2758.999: [Full GC {Heap before GC invocations=326:

Heap

par new generationtotal 235968K, used 29273K [0x70c00000, 0x80c00000, 0x80c00000)

eden space 209792K, 13% used [0x70c00000, 0x72896560, 0x7d8e0000)

from space 26176K,0% used [0x7d8e0000, 0x7d8e0000, 0x7f270000)

tospace 26176K,0% used [0x7f270000, 0x7f270000, 0x80c00000)

concurrent mark-sweep generation total 1835008K, used 1313434K [0x80c00000, 0xf0c00000, 0xf0c00000)

concurrent-mark-sweep perm gen total 33696K, used 21369K [0xf0c00000, 0xf2ce8000, 0xf8c00000)

2759.000: [ParNew: 29273K->983K(235968K), 0.0133278 secs]2759.014: [CMS2777.123: [CMS-concurrent-mark: 20.209/20.353 secs]

(concurrent mode failure): 1313434K->1313732K(1835008K), 60.4770959 secs] 1342707K->1313732K(2070976K), [CMS Perm : 21369K->21364K(33696K)] Heap after GC invocations=327:

Heap

par new generationtotal 235968K, used 0K [0x70c00000, 0x80c00000, 0x80c00000)

eden space 209792K,0% used [0x70c00000, 0x70c00000, 0x7d8e0000)

from space 26176K,0% used [0x7f270000, 0x7f270000, 0x80c00000)

tospace 26176K,0% used [0x7d8e0000, 0x7d8e0000, 0x7f270000)

concurrent mark-sweep generation total 1835008K, used 1313732K [0x80c00000, 0xf0c00000, 0xf0c00000)

concurrent-mark-sweep perm gen total 35608K, used 21364K [0xf0c00000, 0xf2ec6000, 0xf8c00000)

} , 60.4921313 secs]

Message was edited by:

tsriram07

Message was edited by:

tsriram07

[5965 byte] By [tsriram07a] at [2007-11-26 19:40:48]
# 1

Try adding

-XX:+DisableExplicitGC

And if it is support in 1.4.2, also try

-XX:+CMSClassUnloadingEnabled

-XX:+CMSPermGenSweepingEnabled

Also search for UseCMSCompactAtFullCollection and CMSFullGCsBeforeCompaction in http://java.sun.com/docs/hotspot/gc1.4.2/faq.html It will explain how Full GC can occur even if the heap is not full. In short UseCMSCompactAtFullCollection and CMSFullGCsBeforeCompaction control when and how a Full GC will occur when memory is too fragment to get a block of memory.

Caffeine0001a at 2007-7-9 22:21:15 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2
Not an expert, but it could be running Full's to expand your perm gen.
haymaker989a at 2007-7-9 22:21:16 > top of Java-index,Java HotSpot Virtual Machine,Specifications...