Page History

...

What's an oop, and why should they be compressed?

An "oop", or "ordinary object pointer" in HotSpot parlance is a managed pointer to an object. It is normally the same size as a native machine pointer, which means 64 bits on an LP64 system. On an ILP32 system, there is a maximum heap size of somewhat less than 4Gb or so, which is not enough for many applications. On an LP64 system, though, the heap of for any given run is almost twice as big as may have to be around 1.5 times as large as for the corresponding IPL32 system (assuming the run fits both modes). This is due to the expanded size of managed pointers. Memory is pretty cheap, but these days bandwidth and cache is in short supply, so doubling significantly increasing the size of the heap , just to get over the 4Gb limit , is painful.

(Additionally, on x86 chips, the ILP32 mode provides half the usable registers that the LP64 mode does. SPARC is not affected this way; RISC chips start out with lots of registers and just widen them for LP64 mode.)

...

• the klass field of every object
• every oop instance field
• every element of an oop array (objArray)
• in a constant pool... (what is the rule here??)
• (what else is compressed??)

...

Likewise, method calling sequences, either interpreted or compiled, do not deal with use compressed oops.

In compiled code, oops are compressed or not according to the outcome of various optimizations. Optimized code may succeed in moving a compressed oop from one location in the managed heap to another without ever decoding it. Likewise, if the chip (i.e., x86) supports addressing modes which can be used for the decode operation, compressed oops might not be decoded even if they are used to address object fields or array elements.

...