When You're at Your Limit

It's often the case that we advise users of large applications to use large young generations. The rational is that large applications (very often multithreaded) have large allocation rates and a large young generations is good because it allows more time between minor collections. One case where that is not a good idea is when you're using the largest heap you can (e.g. close to 4G on a 32 bit system) and the live data is bigger than will fit in the tenured generation.

When the young generation fills up, we want to do a minor collection. Minor collections are in general more productive (the young generation tends to have more garbage) and faster (the time to collect depends largely on the amount of live data in the young generation and not on the about of garbage). If, however, when we're contemplating a minor collection and the tenured generation is full, the garbage collector will think that it's time to do a major collection and collect both the tenured generation and the young generation. If the tenured generation is actually full (or very nearly full) of live data, then the tenured generation may still be full at the end of the major collection. The collection worked, but the next time the young generation fills up, a major collection will again be done.

If you find yourself in this situation, try reducing the size of the young generation and increasing the size of the tenured generation accordingly. The goal is to have enough free space available in the tenured generation after a major collection so that the next collection can be a minor collection. Even if you can only manage enough free space in the tenured generation to do 1 minor collection, it's a win. Sizing the generations so you can get a few minor collections between major collections would be sweeter, but that all depends on how close you are to your limit.

Comments:

Hi,

Interesting. As I've said before I never feel sure how to size the new vs tenured generations.

It would be especially good if newer GCs could (a) automatically tune the size of the new/tenured areas and (b) tune the number of new collections before something is tenured. (This last one would be doubly good for CMS if it could decide that some delay before tenuring would be good unlike its default.)

As I have suggested to Steve Goldman with tiered compilation performance at start-up, it may be beneficial to retain some stats from one run to the next, for two partially antagonistic reasons: (1) special-case behaviour before steady-state is reached and (2) faster/better recongition and handling of stead-state garbage generation.

Rgds

Damon

Posted by Damon Hart-Davis on January 11, 2007 at 02:01 AM PST #

I'm not sure I've replied to Damon about this or not but the idea of saving state across runs is something we're interested in doing. When it happens tiered compilation and gc will surely use it. The big question is when it will happen. I know people want to do it for JDK7 but I know that there are problems to solve that people are struggling with. It isn't entirely clear that without code caching this will help startup since piles of compiles early on will surely hurt but steady state is certainly likely to happen sooner.

Posted by fatcatair on January 12, 2007 at 12:03 AM PST #

We have a app with 8GB heap - young gen = 1gb (with surv ratio = 1). Using concurrentmarkandsweep GC. Observation 1 : The transient mem seems to survive the minor collections and the tenured size increases steadily. Observation 2 : The GC tries to kick in at 75% (initiatingOccupancy) but its unable to collect anything and just starts spending a large amount of time in attempting to do it. Eventually running out of memory. We profiled the app and there is no leak. Is is that the GC type used is no appropriate for this appln or could it be fragmentation in the tenured space? Thanks

Posted by Giriraj Vengurlekar on January 12, 2007 at 02:50 AM PST #

Hi Steve,

Yes, you did answer me on this, more than once, thanks! But I have an agenda to push you know... :P

I think that remembering what would have been good for start-up (GC, compilation) with the benefit of hindsight rather than guessing each time is likely to be a good thing.

Rgds

Damon

Posted by Damon Hart-Davis on January 12, 2007 at 05:13 AM PST #

Giriraj,

Please send some GC logs showing the problem to

http://java.sun.com/docs/forms/gc-sendusmail.html

and we'll take a look at them. Please use the flags

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

and include the command line.

Posted by Jon Usmasatmi on January 16, 2007 at 04:12 AM PST #

Post a Comment:
Comments are closed for this entry.
About

jonthecollector

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today