why objects are propgated to old instead of aging in from space

I am seeing when eden is 100% and from space is 100% full before GC.

After GC from space is only 10-15% full but and most of the objects is propagated to old space rather then allowing aging to happen in newspace.

I have question about behavior which we seen today in on eour env.

We are in 1.4.2.09 jdk

Solaris 9

Apps server: weblogic

-Xms2560m -XX:+UseConcMarkSweepGC -XX:+UseP

arNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -Xmx2560m -XX:NewSize=640M -XX:MaxNewSize=640M -XX:MaxTenuringThreshold=6 -XX:SurvivorRatio=5 -XX:TargetS

urvivorRatio=80 -XX:MaxPermSize=256M

This is output from GC. My question is at the end for GC invocation 25072

386979.655: [GC {Heap before GC invocations=25070:

Heap

par new generationtotal 449408K, used 421988K [0x49000000, 0x69000000, 0x69000000)

eden space 374528K, 100% used [0x49000000, 0x5fdc0000, 0x5fdc0000)

from space 74880K, 63% used [0x646e0000, 0x67539300, 0x69000000)

tospace 74880K,0% used [0x5fdc0000, 0x5fdc0000, 0x646e0000)

concurrent mark-sweep generation total 2097152K, used 958892K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94066K [0xe9000000, 0xf21e8000, 0xf9000000)

386979.656: [ParNew

Desired survivor size 61341696 bytes, new threshold 2 (max 5)

- age1:53505440 bytes,53505440 total

- age2:8843896 bytes,62349336 total

- age3:4630984 bytes,66980320 total

- age4:4953056 bytes,71933376 total

- age5:4592336 bytes,76525712 total

: 421988K->74880K(449408K), 0.4116928 secs] 1380881K->1047351K(2546560K) Heap after GC invocations=25071:

from space 74880K, 63% used [0x646e0000, 0x67539300, 0x69000000)

tospace 74880K,0% used [0x5fdc0000, 0x5fdc0000, 0x646e0000)

concurrent mark-sweep generation total 2097152K, used 958892K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94066K [0xe9000000, 0xf21e8000, 0xf9000000)

386979.656: [ParNew

Desired survivor size 61341696 bytes, new threshold 2 (max 5)

- age1:53505440 bytes,53505440 total

- age2:8843896 bytes,62349336 total

- age3:4630984 bytes,66980320 total

- age4:4953056 bytes,71933376 total

- age5:4592336 bytes,76525712 total

: 421988K->74880K(449408K), 0.4116928 secs] 1380881K->1047351K(2546560K) Heap after GC invocations=25071:

Heap

par new generationtotal 449408K, used 74880K [0x49000000, 0x69000000, 0x69000000)

eden space 374528K,0% used [0x49000000, 0x49000000, 0x5fdc0000)

from space 74880K, 100% used [0x5fdc0000, 0x646e0000, 0x646e0000)

tospace 74880K,0% used [0x646e0000, 0x646e0000, 0x69000000)

concurrent mark-sweep generation total 2097152K, used 972471K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94066K [0xe9000000, 0xf21e8000, 0xf9000000)

} , 0.4122458 secs]

386982.508: [GC {Heap before GC invocations=25071:

Heap

par new generationtotal 449408K, used 348578K [0x49000000, 0x69000000, 0x69000000)

eden space 374528K, 73% used [0x49000000, 0x59b488d8, 0x5fdc0000)

from space 74880K, 100% used [0x5fdc0000, 0x646e0000, 0x646e0000)

tospace 74880K,0% used [0x646e0000, 0x646e0000, 0x69000000)

concurrent mark-sweep generation total 2097152K, used 972471K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94067K [0xe9000000, 0xf21e8000, 0xf9000000)

386982.509: [ParNew

Desired survivor size 61341696 bytes, new threshold 1 (max 5)

- age1:74441024 bytes,74441024 total

- age2:2202704 bytes,76643728 total

: 348578K->74880K(449408K), 0.4058586 secs] 1321049K-1151354K(2546560K) Heap after GC invocations=25072:

Heap

par new generationtotal 449408K, used 74880K [0x49000000, 0x69000000, 0x69000000)

eden space 374528K,0% used [0x49000000, 0x49000000, 0x5fdc0000)

from space 74880K, 100% used [0x646e0000, 0x69000000, 0x69000000)

tospace 74880K,0% used [0x5fdc0000, 0x5fdc0000, 0x646e0000)

concurrent mark-sweep generation total 2097152K, used 1076474K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94067K [0xe9000000, 0xf21e8000, 0xf9000000)

} , 0.4064259 secs]

386984.238: [GC {Heap before GC invocations=25072:

Heap

par new generationtotal 449408K, used 449408K [0x49000000, 0x69000000, 0x69000000)

eden space 374528K, 100% used [0x49000000, 0x5fdc0000, 0x5fdc0000)

from space 74880K, 100% used [0x646e0000, 0x69000000, 0x69000000)

tospace 74880K,0% used [0x5fdc0000, 0x5fdc0000, 0x646e0000)

concurrent mark-sweep generation total 2097152K, used 1076474K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94067K [0xe9000000, 0xf21e8000, 0xf9000000)

386984.238: [ParNew

Desired survivor size 61341696 bytes, new threshold 5 (max 5)

- age1:6490896 bytes,6490896 total

: 449408K->6363K(449408K), 0.5403124 secs] 1525882K->1241212K(2546560K) Heap after GC invocations=25073:

Heap

par new generationtotal 449408K, used 6363K [0x49000000, 0x69000000, 0x69000000)

eden space 374528K,0% used [0x49000000, 0x49000000, 0x5fdc0000)

from space 74880K,8% used [0x5fdc0000, 0x603f6e60, 0x646e0000)

tospace 74880K,0% used [0x646e0000, 0x646e0000, 0x69000000)

concurrent mark-sweep generation total 2097152K, used 1234849K [0x69000000, 0xe9000000, 0xe9000000)

concurrent-mark-sweep perm gen total 149408K, used 94067K [0xe9000000, 0xf21e8000, 0xf9000000)

} , 0.5408648 secs]

Why at this time it propagated (1234849K ?1076474K = 158M)

Why it has n抰 gone to aging in from and to space.

Our survivor ratio = 5 and tenuringthreshold = 5

becasu eof thsi large propagation, till it hit CMS gc again, parnewGC takes 15-20 minutes

[6146 byte] By [anujlal2a] at [2007-11-26 15:53:20]
# 1

> I am seeing when eden is 100% and from space is 100%

> full before GC.

From space being 100% full often indicates that survivor space

overflow may have occurred. This will almost always be followed by the

reduction of tenuring threshold in the next collection in an effort

to hit the TargetSurvivorRatio chosen.

>

> After GC from space is only 10-15% full but and most

> of the objects is propagated to old space rather then

> allowing aging to happen in newspace.

>

This is because of some sudden volatility in your application

at the previous scavenge which caused the tenuring threshold

to be lowered in anticipation of similar behaviour at the next

scavenge, which however did not occur. My guess is that at the

previous GC epoch your program suddenly allocated a

large object (for example, think HashMap resizing, which can

often lead to such a sudden spike in allocation).

> Why at this time it propagated (1234849K ?1076474K =

> 158M)

> Why it has n抰 gone to aging in from and to space.

> Our survivor ratio = 5 and tenuringthreshold = 5

Recall you have a _max_ trenuring threshold of 5.

The actual tenuring threshold at any time is shown

in your "PrintTenuringDistribution" output and is

adjusted between 0 and 5 in response to object

birth-death rates and lifetimes.

Note that some amount of tenuring is expected and

OK; even some "more than normal" promotion during

certain volatile periods, as long as there is enough

time -- and spare concurrency -- for the CMS collector

to collect the resulting dead objects before a scavenge

is deemed impossible. (We have talked about this

in other communication.)

>

> becasu eof thsi large propagation, till it hit CMS gc

> again, parnewGC takes 15-20 minutes

From looking at your more complete logs (not shown here),

the very long GC's are full gc's that occur as a result of

concurrent mode failure. The pause is exacerbated as

an ongoing concurrent phase is completed before the

ensuing mark-compact collection takes over.

The longer scavenges prior to the concurrent mode

failure are almost certainly the result of allocation slowness

caused by the exhaustion of the free list inventories.

I'd suggest moving to 1.4.2_13 where the pessimal

full promotion guarantee can be avoided once you

enable promotion failure handling (+HandlePromotionFailure;

this is the default with 5.0 and 6.0, so an upgrade would be even

better if possible since there are many other improvements in

the platform in general, and also in the CMS collector

in particular). You will also perhaps need to increase

your old generation size and possibly reduce the

CMS initiating threshold so as to keep fragmentation

in check. In 6.0 in particular are some improvements

that help keep fragmentation under control by estimating

free block demand more correctly than in previous releases.

ramki_at_jdca at 2007-7-8 22:13:47 > top of Java-index,Java HotSpot Virtual Machine,Specifications...