CODEWITHSUNDEEP
javajbossgarbage-collectionjvm
M.ES
M.ES

Reputation: 940

Why the JVM always starts with a FULL GC?

I am performing tuning benchmarks on a web application that is running on JBoss AS5.

I am creating different scenarios using JMeter, starting from low load till stress load.

What I have noticed is that the GC log starts always with a full GC.

Can someone explain to me this behavior?

Thanks in advance.

FWIW, here is a snippet from a GC log:

17.560: [Full GC [PSYoungGen: 44456K->0K(458752K)] [ParOldGen: 0K->4385K(1572864K)]      44456K->4385K(2031616K) [PSPermGen: 11565K->11555K(262144K)], 0.9226691 secs]
72.478: [GC [PSYoungGen: 393216K->30720K(458752K)] 397601K->35105K(2031616K), 0.1787110    secs]
112.137: [GC [PSYoungGen: 423936K->38912K(458752K)] 428321K->43297K(2031616K), 0.2197971 secs]
188.297: [GC [PSYoungGen: 432128K->54272K(458752K)] 436513K->58657K(2031616K), 0.3034273 secs]
309.100: [GC [PSYoungGen: 447488K->60416K(458752K)] 451873K->64801K(2031616K), 0.3111470 secs]
430.354: [GC [PSYoungGen: 453632K->65536K(454848K)] 458017K->72129K(2027712K), 0.3374716 secs]
546.078: [GC [PSYoungGen: 454848K->65536K(415104K)] 461441K->78881K(1987968K), 0.3746511 secs]
652.116: [GC [PSYoungGen: 415104K->40960K(436928K)] 428449K->88641K(2009792K), 0.3895185 secs]
765.134: [GC [PSYoungGen: 390528K->28672K(437632K)] 438209K->94882K(2010496K), 0.2703870 secs]
870.726: [GC [PSYoungGen: 380800K->23552K(375680K)] 447010K->102114K(1948544K), 0.1948568 secs]
976.144: [GC [PSYoungGen: 375680K->18432K(436096K)] 454242K->110306K(2008960K), 0.1734677 secs]

Upvotes: 4

Views: 900

Answers (2)

M.ES
M.ES

Reputation: 940

With the help of Peter Johnson from the Jboss Community. I've been able to know the answer of this question.

I am writing it here to share it with you.

The call to System.gc() is coded into the app server (or into one of the libraries it uses - I know the the RMI libraries like to make GC calls), I suspect as it transitions from bootstrap to the app server itself. I think it might also perform another GC or two after deployment or other major initialization activity. I think the idea behind this was to have the heap as clean of junk as possible before handling user requests. Of course, that made sense years ago when when servers didn't have that much memory and heaps were smaller. I have seen this behavior in JBoss AS release from 4.0.x up through 5.x (haven't monitored GC behavior on 6).

Upvotes: 0

Peter Lawrey
Peter Lawrey

Reputation: 533492

It doesn't always start with a GC, you can have a program which never GCs.

However when the JVM starts it uses a minimal amount of memory by default.

The application is building data structures and high percentage of objects will be retained. This is not normal behaviour and the survivor space can be exhausted. The JVM is tuned to assume most objects which are newly created will be discarded. When the survivor space is exhausted a Full GC is triggered.

Since you know how much memory your application will grow to you can use an option like

-ms512m -mx1g

The full GC will go away and you will collect less often.

Upvotes: 2

Related Questions