Menu
Objects are assigned and copied by reference. In other words, a variable stores not the “object value”, but a “reference” (address in memory) for the value. So copying such a variable or passing it as a function argument copies that reference, not the object itself.
References have a typical size of 4 bytes on 32-bit platforms and on 64-bits platforms with heap boundary less than 32Gb (-Xmx32G), and 8 bytes for this boundary above 32Gb.
An object reference is information on how to find a particular object. The object is a chunk of main memory; a reference to the object is a way to get to that chunk of memory. The variable str does not actually contain the object, but contains information about where the object is.
A reference is an address that indicates where an object's variables and methods are stored. You aren't actually using objects when you assign an object to a variable or pass an object to a method as an argument. You aren't even using copies of the objects. Instead, you're using references to those objects.
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With