This is Jon Masamitsu's reply to the question (This has not been edited in any way and represents him 100%)
In the young generation there are 3 spaces - eden plus 2 survivor
spaces. This organization is to enable the collection of the young generation. See
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
for more details. In calculating the total size of the heap, only 1 on the survivor spaces is being counted. That's because only
eden + 1 survivor space is available to the application for allocations.
That may be where the rest of the space is. If you add -XX:+PrintHeapAtGC
you will see something like
Heap PSYoungGen total 10752K, used 368K [0xf1000000,0xf1c00000, 0xfbc00000)
eden space 9216K, 4% used [0xf1000000,0xf105c308,0xf1900000)
from space 1536K, 0% used [0xf1a80000,0xf1a80000,0xf1c00000)
to space 1536K, 0% used [0xf1900000,0xf1900000,0xf1a80000)
PSOldGen total 24576K, used 0K [0xdb800000, 0xdd000000, 0xf1000000)
object space 24576K, 0% used [0xdb800000,0xdb800000,0xdd000000)
PSPermGen total 16384K, used 1489K [0xd7800000, 0xd8800000,
0xdb800000)
object space 16384K, 9% used [0xd7800000,0xd7974540,0xd8800000)
Which will tell you the sizes of the survivor spaces. By the way, the
perm generation is separate from the Java heap.
Notice the last statement he says "the perm generation is separate from the Java heap". I hope this statement more or less settles the issue i have been hearing for 10,000 years (You can verify this by downloading and browsing the code for it ... it will take you some time but the benefits are tremendous :D )
