Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.8K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 439 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
What does a object references on stack actually look like?

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.
Answers
-
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 anObject
and aMountainBike
(until such time asobj
is assigned another object that is not aMountainBike
). 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. . . .