# Compressed Oops

	An "oop", or ordinary object pointer in Java Hotspot parlance, is a
	managed pointer to an object. An oop is normally the same size as a
	native machine pointer, which means 64 bits on an LP64 system. On an
	ILP32 system, maximum heap size is somewhat less than 4 gigabytes,
	which is insufficient for many applications. On an LP64 system, the
	heap used by a given program might have to be around 1.5 times larger
	than when it is run on an ILP32 system. This requirement is due to the
	expanded size of managed pointers. Memory is inexpensive, but these
	days bandwidth and cache are in short supply, so significantly
	increasing the size of the heap and only getting just over the 4
	gigabyte limit is undesirable.

	Managed pointers in the Java heap point to objects which are aligned on
	8-byte address boundaries. Compressed oops represent managed pointers
	(in many but not all places in the JVM software) as 32-bit object
	offsets from the 64-bit Java heap base address. Because they're object
	offsets rather than byte offsets, they can be used to address up to
	four billion objects (not bytes), or a heap size of up to about 32
	gigabytes. To use them, they must be scaled by a factor of 8 and added
	to the Java heap base address to find the object to which they refer.
	Object sizes using compressed oops are comparable to those in ILP32
	mode.

	The term decode is used to express the operation by which a 32-bit
	compressed oop is converted into a 64-bit native address into the
	managed heap. The inverse operation is referred to as encoding.

	Compressed oops is supported and enabled by default in Java SE 6u23 and
	later.  In Java SE 7, use of compressed oops is the default for 64-bit
	JVM processes when -Xmx isn't specified and for values of -Xmx less
	than 32 gigabytes. For JDK 6 before the 6u23 release, use the
	-XX:+UseCompressedOops flag with the java command to enable the
	feature [1].


# Zero-Based Compressed Ordinary Object Pointers (oops)

	When using compressed oops in a 64-bit Java Virtual Machine process,
	the JVM software asks the operating system to reserve memory for the
	Java heap starting at virtual address zero. If the operating system
	supports such a request and can reserve memory for the Java heap at
	virtual address zero, then zero-based compressed oops are used.

	Use of zero-based compressed oops means that a 64-bit pointer can be
	decoded from a 32-bit object offset without adding in the Java heap
	base address. For heap sizes less than 4 gigabytes, the JVM software
	can use a byte offset instead of an object offset and thus also avoid
	scaling the offset by 8.  Encoding a 64-bit address into a 32-bit
	offset is correspondingly efficient.

	For Java heap sizes up around 26 gigabytes, any of Solaris, Linux, and
	Windows operating systems will typically be able to allocate the Java
	heap at virtual address zero [1].





# References

1. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/performance-enhancements-7.html