I need some memory/heap clarification
Hello all,
I am trying to figure out what is the difference between perm space, perm gen, old gen and tenure. On a lot of sights they use different combinations of these as synonyms. I find that difficult to believe when http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html#gccapacity_option has a capacity for both perm gen and perm space (PGC and PC). I am most interested in the perm gen vs perm space.
Thank you for any clarification you can give.
(Bleah! Formatting on this forum seems to be broken, so this is missing the paragraph breaks.)
You might want to look at http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf which describes the various "generations" in Sun's HotSpot Java virtual machine.
The difference between a "space" and a "generation" is that a generation can be made up of several spaces. For example, the young generation in the HotSpot JVM is made up of an "eden" space and two survivor spaces (called "from" space and "to" space). We don't currently have any other generations that have more than one space in them, but we have the framework for it, and we like to isolate tools from changes in implementations, so we have a list of generations, each of which can contain a list of spaces.
The use of an "old" or "tenured" generation depends on your choice of collection algorithm. At Sun we happen to like generational collectors, but for example, other vendors have gotten away without them for years. If you only have a single generation, then you don't "promote" or "tenure" objects into an "old" generation. Hmm, conversely, other vendors have "small" object areas and "large" object areas, which you could think of as "spaces" within their single generation systems, if it helps as an alternative example.
The "permanent" generation in the Sun JVM is for objects that the JVM wants to have the garbage collector manage, but which are not allocated by the Java application itself. Information about loaded classes goes in there, along with any static fields for those classes (just the static fields, not the objects referenced from the static fields: those are in the regular Java object heap because Java code allocates them), and random other bits like any interned Strings (which we sometimes argue about whether they belong there), etc. The point is that the garbage collector can clean up that storage when classes are unloaded, interned Strings become unreferenced, etc.
You can watch the sizing of the various generations with the -XX:+PrintGCDetails command line flag. If you really want to watch the sizings of the spaces, you can run with the -XX:+PrintHeapAtGC flag, but be prepared for several lines before and after each collection. Most people find -XX:+PrintHeapAtGC to be more detail than they want.
null
null
