Java Statics Primitives, Objects, Methods and the Heap (Memory Management & Best Practices)

Question

Okay, so I have been developing in Java for a little over a year now and am making an effort to dive deeper into the language and its best practices.

So here is what I know:

• Java "passes by type" - that is primitives pass by copy and object reference pass by copy (references point to their object on the heap).

• Primitive instance variables and references live in their class object in the heap and local primitives and references live on the stack (in their respective stack frame).

• Perm Gen. memory space is where class meta data is stored (used for reflection).

• The Heap has an Eden space where new objects are places, a Young space where objects who have survived a GC are kept and a Tenured space where long lived objects are placed.

So here is what I would like to understand:

• Where do static and static final primitives and references live that the JVM is able to use a single instance?

• Are static and static final objects stored in the Heap (I assume they are moved to tenured)?

• What is considered the best practice in terms of the number of static final references in an application?

• Will creating more static final references decrease the amount of Heap space in JVM?

I have read many different explanations about this (all differed) and would love if a seasoned veteran in the Java language could provide a good explanation. Thanks in advance!

Answer 1

The young space includes the eden space and survivor spaces.

Where do static and static final primitives and references live that the JVM is able to use a single instance?

Its not defined, but in the Sun/Oracle JVM, static fields live in a special object for class fields. You have one instance per class loader so static fields can have multiple instances.

Are static and static final objects stored in the Heap (I assume they are moved to tenured)?

In the Sun/Oracle Java 7 they are. They could be in the Perm Gen or any where else.

What is considered the best practice in terms of the number of static final references in an application?

Keep them to a minimum.

Will creating more static final references decrease the amount of Heap space in JVM?

If you can change a final field into a static final field, this can save some space (if you have multiple instances) However, clarity is usually more important than performance. (And I would do it for clarity)

BTW: I have been developing in Java for 13 years.

So there can be multiple instances of static fields - does the JVM alter each instance

They are independent. Each classloader can load its own version of a class (the code doesn't have to be the same) and each gets its own static fields (they don't have to be the same either)

if a static field is changed (ie. static int instanceCount where instanceCount++ is executed on each object construction)?

No.

Also, Objects can be moved to Perm Gen?

No. Must some data which is not defined in one location can be anywhere depending on the implementation and version.

Is Perm Gen. considered to be part of the Heap?

It is part of the old gen = tenured + perm gen.

Young gen = eden + survivor space * 2

Maximum Heap Size limits the young gen & tenured total. Perm gen and direct memory have their own limits. Memory mapped files done follow any of these limits.

This is true for the default parallel collector and the concurrent mark sweep.

The G1 collector doesn't divide up the spaces the same way.

---

Links for more details

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Java heap terminology: young, old and permanent generations?

http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html