How big is an object reference in Java and precisely what information does it contain?

Question

As a programmer I think of these as looking like "the java.lang.Object at address 1a234552" or similar for something like the s in

Object s = "hello";

Is this correct? Therefore are all references a fixed size?

Answer 1

While on many VMs the size of a reference is the native pointer size (i.e. 32 bits for a 32 bit JVM and 64 bits for a 64 bit JVM) this isn't guaranteed - and in particular HotSpot either does now or soon will support "Compressed Oops" which are 32 bit references in a 64 bit JVM. (That doesn't mean that every reference is compressed - read the linked article for more information, and there are plenty of blog posts about it too.)

In response to another comment, note that the reference itself is typically just a way of addressing the object itself. Whether it's a direct memory pointer or not, its goal is to get to the data for the object. That's basically all that really matters. If there's some "spare" bits (e.g. it's a 64-bit reference and you don't need all of that width just to represent the object's location) then the VM can use that data for other information such as its type, which may allow some optimisations. (See Tom's comment for more details.)

The object itself contains type information (probably in the form of a reference to the instance of Class, or something similar - I don't know in enough detail) as well as other necessary "stuff" in the header, before you get to the user data for the object.

Answer 2

It is not a part of JLS or JVM Spec, but in practice it will be an address: 32 bit on 32 bit CPU, 64 at 64.

pqism: Okay got you, because after compilation we no longer care about the declared type?

We do care. That is why Class objects are there. In fact, from the other answers you can see that we care about types in runtime enough to optimize the way we work with them by putting part of type information into reference.

Answer 3

The size of an object reference depends on the JVM and machine architecture. Generally, on a 32-bit machine it is 32 bits and on a 64-bit machine it is 64 bits. However, I think that the OpenJDK 7 JVM will have support for "compressed pointers" that will save some room on 64-bit machines.

The information about the object's type is stored in the object itself; that is, if you follow the 32-bit or 64-bit pointer (or, more likely, handle) to the object, you would find another pointer to a Class instance that describes the type, as well as the data fields of the object.

Answer 4

I just want to add my 0.02$ that on 64-bit platforms, the reference can have 32 bits or 64 bits.

It can be of a 32 bit size when Compressed OOP is enabled (on by default).

The other way it can be of 32 bits is when the heap is smaller then 4 GB and it fits in the initial virtual space of 4 GB. For example:

0                            4GB
..................................................
|   < your heap fits here>    |

In such a case, the source code says that this is UnscaledNarrowOop type of heap alignment and for that type, the the references have 32 bits.

Answer 5

Most people tend to see a reference to an object as a C-language-like-memory-pointer. While this is not technically correct, most implementations do implement it as a pointer. In case of compressed object pointers for example, the JVM stores only bits 3 to 34 of the 64-bit pointer on a 64 bit platform. Other implementations could also choose to use a different scheme: the reference could be an index into an pointer array containing all objects.