Skip to Main Content
Forums

Java Programming

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

What does a object references on stack actually look like?

shankernaikJun 24 2017 — edited Jun 24 2017

As per the documentation :

In some of Sun's implementations of the Java virtual machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers:

one to a table containing the methods of the object and

a pointer to the Class object that represents the type of the object, and

the other to the memory allocated from the heap for the object data.

So given,  two classes A and B as follows :

  1. class A{  
  2.    void m1(){  
  3.    System.out.println(" from m1 method ");  
  4.    }  
  5. }  
  6.   
  7. class B extends A {  
  8.    void m2(){  
  9.    System.out.println(" from m2 method ");  
  10.    }  
  11. } 

In main method I make following objects, what will their bit pattern refer to? I have commented my understanding, correct me if I am wrong.

A a1 = new A();

// a pointer to dispatch table of a1 contains only method m1.

// a pointer to the memory allocated from the heap for the object data.

// a pointer to Class class object of A


B b1 = new B();

// pointer to dispatch table of b1 contains method m1 and m2.

// a pointer to the memory allocated from the heap for the object data.

// a pointer to Class class object of B

A a2 = new B();

// What will the dispatch table of a2 be?

// a pointer to the memory allocated from the heap for the object data.

           // Which Class class object will it point, A or B ?

Thanks in advance.

Comments

unknown-7404

A better question is: why do you care what the PHYSICAL implementation is? That is NOT reliable since it is ALWAYS subject to change by the vendor.

Although the physical implementation may be interesting knowing it won't really help you with Java. What you need to know is the LOGICAL relationships between the objects.

As per the documentation :
In  some of Sun's implementations of the Java virtual machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers: one to a table containing the methods of the object and a pointer to the Class object that represents the type of the object, and the other to the memory allocated from the heap for the object data.

ALWAYS provide the attribution of any quotes. I presume you are referring to the Java Virtual Machine Spec

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html

2.7. Representation of Objects

The Java Virtual Machine does not mandate any particular internal structure for objects. 
In some of Oracle’s implementations of the Java Virtual Machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers: one to a table containing the methods of the object and a pointer to the Class object that represents the type of the object, and the other to the memory allocated from the heap for the object data.

Did you see that first KEY sentence?

There is no 'mandate' for the internal structure of objects. Vendors are free to use ANY internal structure they wish.

Did you notice the words 'In some of ..' at the start of the second sentence. That tells you that what follows may apply to only SOME of Oracle's implementations and, thus, may NOT apply to others.

Taken together that means that unless the Vendor publishes detailed info about the internal structure they use (and they generally don't publish that info) then you can't be certain WHAT they do 'under the covers'.

Although the physical implementation may be interesting knowing it won't really help you with Java. What you need to know is the LOGICAL relationships between the objects.

// Which Class class object will it point, A or B ?

After reading the above you should now understand that the PHYSICAL implementation isn't available. You need to understand the LOGICAL implementation.

If you construct an instance of 'B', which you did, then the PHYSICAL entity is an instance of B (which, of course, is also an instance of A due to inheritance).

When you assign that instance of 'B' to a variable of type 'A' you restrict the VIEW of that object to ONLY those attributes and methods inherited from class A. The 'physical' b instance, typically on the heap, still has the other attributes and methods that make it a 'B' but those are NOT visible/accessible to you when you access the instance using the 'A' variable.

As the doc above states the actual physical way in which that 'filtering' is done depends on the vendor and the way they physically implement that filtering.

They could use the 'B' method table but not allow access to any new b methods or they could construct a 'filtered' method table for 'B' that doesn't include the new b methods. Then vendor is free to do it anyway they want.

They MUST use the 'B' implementation of any overridden methods of 'A' - so they can't just use the 'A' method table directly. They could, however, copy the 'A' method table and replace the 'A' method reference with the 'B' method reference for overridden methods.

Logically it appears as if you are looking at the instance through a mask/filter. For a hierarchy C -> extends B -> extends A you can look at a 'C' instance as if was an 'A' and you will only be able to see/access attributes/methods that belong to an A instance (although if overridden you will see/access the C version of them.

Or you can look at the 'C' as if it were a 'B' - the list of methods will only include those that are part of a 'B' (which can include those from an 'A').

See the examples in the Inheritance and Polymorphism trails of The Java Tutorials

https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html 

Casting shows the use of an object of one type in place of another type, among the objects permitted by inheritance and implementations. For example, if we write
Object obj = new MountainBike(); 
then obj is both an Object and a MountainBike (until such time as obj is assigned another object that is not a MountainBike). This is called implicit casting.

https://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html

The LOGICAL way that the correct method to invoke is found is explained in detail in The Java Language Spec

https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.4.4

15.12.4.4. Locate Method to Invoke

The strategy for method lookup depends on the invocation mode. 
. . .
1 - 1
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jul 22 2017
Added on Jun 24 2017
#java
1 comment
249 views