tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: What is the healthy interval length for young gc?
Date Mon, 03 Jan 2011 14:39:42 GMT
Leon Rosenberg wrote:
> 
>> If Major GC's are taking place often, then it must mean that despite the
>> regular copying from the "From" to the "To" parts of the new generation (by
>> the Minor GCs), the JVM is running out of space on the new gen part, and
>> therefore has to do a Major GC to move things to the "old gen".
> 
> Actually no, in my understanding both are independent. I mean the gc
> doesn't start "to copy over" if young is full, it simply cleans young.
> However,
> to quote your article: "Old generation objects are objects that
> survived a few collections in the young generation area", and if
> objects managed to survive longer as they should in the young space,
> they might have been copied to old gen, despite the fact, that they
> are young generation objects by nature (meaning short lifetime). This
> theory is what I'm trying to check.
> 

I admit my earlier poor phrasing.
Another re :
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.Introduction|outline
and particularly sections 4.2 and 5.

According to that, the "old gen" (better named as "tenured" I guess) gets collected by a
Major GC when it needs to be (because it has run out of space).
So it is indeed independent of the minor GCs, in the sense that it is not triggered by it

directly.

But, it is reasonable to assume that it runs out of space because objects are moved there
from the "new gen", when ditto objects have survived "a certain time" in the new gen.
(I believe that this "certain time" is measured in terms of Minor GCs, rather than really

a number of seconds).

It also says : "If survivor spaces are too small, copying collection overflows directly 
into the tenured generation."

So basically, I would say that it boils down (almost) to the same thing.

Scenario :
- the applications create new objects at a furious rate
- the "new gen" fills up rapidly
- a minor GC is triggered when "new" is "sufficiently full"
   The minor GC copies live objects from Eden+From, to "To", and conveniently forgets dead

ones.
- at the same time (?), the minor GC also copies objects which have survided more than n 
minor GCs, to the "old gen". OR, if survivor spaces are too small, then the copying also 
moves objects directly to the "old gen" (I take that as meaning "independently of whether

they have survived n minor GCs or not").
- the old gen fills up. When it reaches a "certain level", this triggers a major GC.

So yes, it would seem that if you increase the "new gen" alone, this may increase the time

before a minor GC happens, thus making it so that objects in the "new gen" will stay 
longer there, thus increase the chance that they will "die" there, before they ever have 
to be moved to old gen.

At least if most of these objects are finally of the short-lived type.


I really suggest that you read the article sections above. They also contain some data 
about different Garbage Collectors and when to use them.  One of these cases may apply to
you.
One would need to find the corresponding Java 1.6 version, but I am particularly intrigued

by what it says about the "Troughput collector" and multiple processors (which they all 
tend to be these days).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message