So please anybody clear my confusion that what the actual process is performed by jvm here....
Greg Charles wrote:Your friend is being somewhat picky. The variable holds a reference, which the JVM can use to locate the object in the heap. The reference is not a physical memory address, so technically it's not a pointer. Conceptually, it's practically the same thing though.
As an implementation detail, with the Azul JVM (which I had the pleasure to work on), the lower 48 bits (I think) is a pointer to the memory address of the object. The rest of the bits is some sort of ID to confirm that it does point to a valid object. With the Sun JVM, I was under the impression that the reference did hold a memory address. Of course, this is purely an implementation detail -- the specification doesn't say that it has to be a direct memory address.
Henry has a good point that the reference might contain the physical memory address of the object, which would be just like a pointer. However, unlike a pointer in C, for example, you can't do arithmetic on a reference to find nearby objects in the heap. For all intents and purposes, the reference is a random, but unique value that lets the JVM find your object. Many variables can hold the same reference value, in which case they are referring to the same object. An object created in a method lives in the heap and survives even after the method completes. If it was assigned to a local variable in that method, then the reference was on the stack, and is gone after the method completes. The job of the Java garbage collector is to examine the heap looking for objects that have no references either on the heap or in an active stack, and removing them. How it does that is another thing that you should understand in concept, though not necessarily in detail.
It's turtles all the way down. For most practical purposes, a reference is a pointer is a memory address. Everything else is details that you don't need to worry about.