difference between object and reference

When we write,

ClassA obj = new ClassA();

what is the reference and what is the object. I am reading about garbage collection and I am really getting confused by therse two terms. When we say that an object is garbage collected, do we mean the memory allocated by new to obj is being garbage collected.

Is there any text that explains about the heap, stack frame pictorally or using an java code example. I am not able to make a picture of whats happening in the background.

regards,
vijay.

The "new" operator creates a new object of the ClassA type on the heap and returns a reference to the object. The reference is then assigned to the obj variable. As obj is a local variable, it lives on the stack.

Does that help?

Perhaps TIJ gives the best explanation for this.
[ January 03, 2006: Message edited by: Stuart Ash ]

and this 'obj' variable will be popped out of teh stack when the control comes out of the function in which it was declared.

What happens to the memory space in the heap. Is this where garbage collection comes into the picture. It collects the garbage from the heap.

regards,
vijay

It may help to think "garbage collectable heap" (and not just "heap").

When there is no reference to this memory on the gc-heap, then the gc removes the memory the next time it decides to clean up.

Stuart

The 'new' operator will create an object in HEAP an not in STACK.

The memory address of the heap location where the object is strored is the REFERENCE.

All the references are stored on the stack.

The GC will make a reference count for cleanup. If the count becomes 1 the object will be GC'd. The 1 reference will be that of the garbage collector.

Hope I am not making things more complex.

Originally posted by Pradeep KG:
The 'new' operator will create an object in HEAP an not in STACK.

Did someone suggest otherwise?

All the references are stored on the stack.

Nope. If the reference is stored in an instance variable (aka field), it's stored on the heap, obviously. Only local variables (including parameters) are stored on the stack.

The GC will make a reference count for cleanup. If the count becomes 1 the object will be GC'd. The 1 reference will be that of the garbage collector.

No, java garbage collectors don't use reference counts, but more sophisticated algorithms. With only reference counting, an object that is only referenced by unreachable objects wouldn't get garbage collected, leading to memory leaks due to reference circles. Just imagine an object referencing itself.

In other languages, a Java "reference" might be called a pointer or address. A Java variable simply holds the value of the reference/pointer/address, which the Java Virtual Machine uses to find the actual object in memory.

Hope that clarifies rather than obfuscates!

Originally posted by Adam Richards:
In other languages, a Java "reference" might be called a pointer or address. A Java variable simply holds the value of the reference/pointer/address, which the Java Virtual Machine uses to find the actual object in memory.

Hope that clarifies rather than obfuscates!

When the variable is not a primitive you mean.

Originally posted by Ilja Preuss:
The "new" operator creates a new object of the ClassA type on the heap and returns a reference to the object. The reference is then assigned to the obj variable. As obj is a local variable, it lives on the stack.

Does that help?

To add, the starting point to make the distinction is the lifetime-predictability of the variable (reference).

Since, for objects, the lifetime is unpredictable, they are always in the heap.

For in-method variables (primitives and references), like Ilja explains, the lifetime is predictable, and hence in the stack.

For instance variables (primitives and references), the lifetime is unpredictable, hence the heap.

This holds for both references and primitives.

I hope this properly summarizes the concept.

Originally posted by Stuart Ash:

To add, the starting point to make the distinction is the lifetime-predictability of the variable (reference).

Since, for objects, the lifetime is unpredictable, they are always in the heap.

For in-method variables (primitives and references), like Ilja explains, the lifetime is predictable, and hence in the stack.

For instance variables (primitives and references), the lifetime is unpredictable, hence the heap.

This holds for both references and primitives.

I hope this properly summarizes the concept.

Any objections to this? The above sums it up fine? Ilja?
[ January 05, 2006: Message edited by: Stuart Ash ]

Sounds good to me.

The reason that the lifetime place a vital role in deciding between heap and stack is that stack space gets allocated when entering a method, and deallocated when the method is left. That is, we need to exactly know how much space is needed while the method is executed, and the space is only available during the lifetime of the method.

Hi Stuart
I was very confused about this concept and even was going through other threads in which this is discussed.
But your concept of lifetime makes it clear for what is stored on heap and what is stored on stack.Thanks very much .