4

I read on a site ( http://www.rajeshpatkar.com/articles/javarefpnt/ ) that when we instantiate a class i.e 

Emp e = new Emp();

A handle is stored in the variable e, which is not a pointer i.e it does not store the address of object in memory.

The explanation gives an example of array of pointers. The memory address is stored at a[1] position and when the object is moved this position is updated with new address.

So why this array is used instead of directly storing the address (it states that it helps GC, but i didn't understand it ) and updating it (the address stored in e) when the object is moved?

I've spent quite a lot of time in understanding this, but still haven't found an answer that satisfies me. So if you can explain me what actually is stored in the variable 'e' (with an example) it would be quiet helpful.

Thanks :)

Jayesh Saita
  • 327
  • 1
  • 4
  • 9

2 Answers2

10

The usual term is "object reference" (or just "reference"), rather than "handle."

An object reference is an opaque value that uniquely identifies a certain object to the JVM. The form of that value is not defined by the specification other than. I suspect it's typically the size of an int or long, but I don't think even that is covered by either the JLS or the JVM spec. (To give you an idea, the JVM spec expressly points out that even the exact value of null [the special value meaning "no reference"] isn't mandated.)

References are not pointers, although of course since the form of a reference isn't specified, it would be possible for a JVM to be implemented by using pointers as references, so long as that fact couldn't be exploited in a way that violated the spec.

Because references are not pointers, Java doesn't have "pointer arithmetic" like C and its related languages do.

So if you can explain me what actually is stored in the variable 'e' (with an example) it would be quiet helpful.

It's not defined by the spec. It's just a value that uniquely identifies an object (and we can never see that value; the myth that the hex value you see when you use System.out to print an object that doesn't implement toString is the object's reference is just that: a myth). How that value identifies that object is up to the implementation of the JVM. It could be a pointer. It could be an index into an array of pointers. It could be more complex, using different bits from the reference value for different things.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • great explanation mate. I finally understood the concept of handle. Continuing with the array of pointers example i.e 'e' (reference variables) points to a[1] which in turn(i.e a[1]) stores the address of object. Further i came to know that we cannot change the value of 'e' i.e we cannot make 'e' point to a[5] or any other memory in java, only the contents i.e the value stored at a[1] can be changed. What is the reason for this in Java i.e why it is not allowed to make 'e' point to any other location in java? What are the possible risks of allowing it? – Jayesh Saita Apr 18 '17 at 10:47
  • 2
    @JayeshSaita: Glad that helped. *"...Further i came to know that we cannot change the value of 'e'..."* Yes, we can: `e = someOtherObject;` Don't get caught up on how the JVM may implement it. Just: Variables store values. The value stored in reference-type variables is an object reference. That value tells the JVM where the object is. :-) – T.J. Crowder Apr 18 '17 at 10:53
1

A handle is stored in the variable e, which is not a pointer i.e it does not store the address of object in memory.

To all practical purposes you can assume it stores the address of the object in memory.

However, consider in Java you cannot manage memory in an explicit way. That means you cannot make this kind of variables point to a particular position in memory. You can just make this variables point to a particular instance.

Andres
  • 10,561
  • 4
  • 45
  • 63
  • *"To all practical purposes ..."* - except for compressed oops - http://stackoverflow.com/questions/25120546/trick-behind-jvms-compressed-oops – Stephen C Apr 17 '17 at 14:09
  • True, in the case of 64 bit JVMs – Andres Apr 17 '17 at 14:12
  • Not to all practical purposes, I think. There's hashcode() which is usually implemented (though this is not required) by converting object reference to integer, right? If instead it would rely on a pointer in memory, then every GC's movement of this instance would make it return different hashcode, even though the object did not mutate. Which violates contract for hashcode(). – Maksim Gumerov Sep 06 '17 at 05:30