I'm trying to understand how the concepts of young, old and permanent generations in the Java heap terminology, and more specifically the interactions between the three generations.
My questions are:
Assuming you're talking about the Sun JDK/OpenJDK, see the page on the OpenJDK website on Storage Management. There are a couple of links to even more information at the bottom.
The Java virtual machine is organized into three generations: a young generation, an old generation, and a permanent generation. Most objects are initially allocated in the young generation. The old generation contains objects that have survived some number of young generation collections, as well as some large objects that may be allocated directly in the old generation. The permanent generation holds objects that the JVM finds convenient to have the garbage collector manage, such as objects describing classes and methods, as well as the classes and methods themselves.
This seems like a common misunderstanding. In Sun's JVM, the permanent generation is not part of the heap. It's a separate space for class definitions and related data, as well as where interned strings live. Here is a good post on permanent generation.
I like the descriptions given for each space in Sun's guide on JConsole:
For the HotSpot Java VM, the memory pools for serial garbage collection are the following.
- Eden Space (heap): The pool from which memory is initially allocated for most objects.
- Survivor Space (heap): The pool containing objects that have survived the garbage collection of the Eden space.
- Tenured Generation (heap): The pool containing objects that have existed for some time in the survivor space.
- Permanent Generation (non-heap): The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
- Code Cache (non-heap): The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.
Java uses generational garbage collection. This means that if you have an object foo (which is an instance of some class), the more garbage collection events it survives (if there are still references to it), the further it gets promoted. It starts in the young generation (which itself is divided into multiple spaces - Eden and Survivor) and would eventually end up in the tenured generation if it survived long enough.
This article is a very good survey on garbage collectors. It defines the basic concepts and terminology of garbage collection and includes many explanatory drawings. It is a "must read" for anybody who is interested in how automatic memory allocation works; reading it will make it much easier for you to read and understand the various documents that others have pointed at.
(What that document lacks is any information about post-1993 research on garbage collectors, especially the whole business of multi-core systems. Still, you have to learn to walk before learning to run.)