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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
