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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…