Forum Stats

  • 3,836,891 Users
  • 2,262,203 Discussions
  • 7,900,135 Comments

Discussions

Categories

What does a object references on stack actually look like?

shankernaik
shankernaik Member Posts: 2
edited Jun 24, 2017 12:28PM in Java Programming

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 :

class A{     void m1(){     System.out.println(" from m1 method ");     }  }    class B extends A {     void m2(){     System.out.println(" from m2 method ");     }  } 

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.

<span class="pln">A a1 </span><span class="pun">=</span><span class="pln"> </span><span class="kwd">new</span><span class="pln"> A</span><span class="pun">();</span><span class="pln"> </span>

<span class="com">// a pointer to dispatch table of a1 contains only method m1.</span>

<span class="pln">// a pointer to the memory allocated from the heap for the object data.</span>

<span class="pln">// a pointer to Class class object of A<br/></span>

<span class="pln"><br/>B b1 </span><span class="pun">=</span><span class="pln"> </span><span class="kwd">new</span><span class="pln"> B</span><span class="pun">();</span><span class="pln"> </span>

<span class="com">// pointer to dispatch table of b1 contains method m1 and m2.</span><span class="pln"><br/></span>

<span class="pln">// a pointer to the memory allocated from the heap for the object data.</span>

<span class="pln">// a pointer to Class class object of B<br/></span>

<span class="pln">A a2 </span><span class="pun">=</span><span class="pln"> </span><span class="kwd">new</span><span class="pln"> B</span><span class="pun">();</span><span class="pln"> </span>

<span class="com">// What will the dispatch table of a2 be?</span>

<span class="pln">// a pointer to the memory allocated from the heap for the object data.</span>

<span class="pln">           // Which Class class object will it point, A or B ?</span>

Thanks in advance.

Tagged:
· Share on TwitterShare on Facebook

Answers

  • Unknown
    Unknown
    edited Jun 24, 2017 12:28PM

    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.

    <span class="pln">// Which Class class object will it point, A or B ?</span>

    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 writeObject 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. . . .
    · Share on TwitterShare on Facebook
This discussion has been closed.