logical structure/details of a reference variable and object in the memory?

Question

Let\'s say we have a class:

class Class1
{
   int i = 1;
}

and we have a variable:

Class1 ob1 = new Class1();

Answer 1

Does a reference itself stored in a variable ob1 store the information that it refers to an object of Class1?

NO. Reference variable ob1 stores only the reference of the object it points to. And the information about that object is already known to the application (or JVM).

Does the part of the heap where Class1 is stored store the information that it is of Class1 type?

NO. The information about class being loaded is stored in method area. As specified in this link
For each type it loads, a Java virtual machine must store the following kinds of information in the method area:

• The fully qualified name of the type
• The fully qualified name of the type's direct superclass (unless the type is an interface or class java.lang.Object, neither of which have a superclass)
• Whether or not the type is a class or an interface
• The type's modifiers ( some subset of` public, abstract, final)
• An ordered list of the fully qualified names of any direct superinterfaces

How does logically looks like this information? It's a string like application1.Class1 or a reference to some reference types pool?

Inside the Java class file and Java virtual machine, type names are always stored as fully qualified names. For example, the fully qualified name of class Object in package java.lang is representated as java/lang/Object. In the method area, fully qualified names can be represented in whatever form and data structures a designer chooses.

Answer 2

Every java object reference knows its class at runtime; this so-called "run-time type information" is used in code like this:

if (obj instanceof class1) {
  // true!
}

You can also access the class of an object through obj.getClass(). This will return class1.class, an object of class Class<class1>. See the Object.getClass method.

(Note that if your class is parameterized, as class1<T>, the type of T will not be stored at runtime, due to "erasure".)

I don't know whether the class information is stored with the pointer or with the data; it's probably implementation-specific in the jvm; but it hardly matters from a practical standpoint. (So either answer 1 or 2, or both, is "yes").

The answer to 3 is that, as far as a java programmer is concerned, the run-time type information is encapsulated in an object of class Class. Under the covers, a JVM may implement this in one way or another.

Answer 3

Answering your question:

1. No, it doesn't. Reference is just a reference, i.e. some address in heap, where corresponding object is stored. There is no need to store duplicate information about reference type in reference itself, because actually real variable, which contains its reference address could be of various class types.

2. Very strange question. Of course, yes, it does. Furthermore, this "part of heap" is an object, which contains this particular class description. Any Class object contains information about full name of that class, which is described by it.

3. It is not defined as how it looks logically, if you mean its structure:

2.7 Representation of Objects:

The Java virtual machine does not mandate any particular internal structure for objects.

But if we are talking about information about class type - yes, it is just a String object, because "type" of Class object (which it is represent) is just a name of corresponding class.

Answer 4

This is one of the scheme in which the JVM can store the information of the class for the check at runtime using instanceOf.

Every Java virtual machine must have the capability to determine information about its class, given only a reference to an object. This is needed for many reasons, including type-safe casting and the instanceof operator.

This is one way in which a Java virtual machine implementation could associate class information with the instance data for an object. In this figure, a native pointer to a data structure containing class information is stored along with the instance variables for an object. The details in which the various ways a JVM could connect an object's data with its class information are beyond the scope of this article. The important thing to understand here is that class information will in some way be associated with the instance data of objects, and that the instance data includes fields for an object's class and all its superclasses.

Artima post on Object initialization

So when you do instanceOf check the information about the class is accessed via this pointer. But again do keep in mind that the exact implementation about the storage of class information may be implementation specific.