X

Jon Masamitsu's Weblog

  • Java
    January 11, 2007

When You're at Your Limit

Guest Author
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.

Join the discussion

Comments ( 5 )
  • Damon Hart-Davis Thursday, January 11, 2007
    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

  • fatcatair Friday, January 12, 2007
    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.
  • Giriraj Vengurlekar Friday, January 12, 2007
    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
  • Damon Hart-Davis Friday, January 12, 2007
    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

  • Jon Usmasatmi Tuesday, January 16, 2007
    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.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.