Page History

The 64-bit VM with compressed oops uses an arbitrary address
for the narrow oop base which is calculated as java heap base
minus one (protected) page size for implicit NULL checks to work.
This means a generic field reference is
<narrow-oop-base> + (<narrow-oop> << 3) + <field-offset>.
If the narrow oop base can be made to be zero (the java heap
doesn't actually have to start at offset zero), then a generic
field reference can be just (<narrow-oop << 3) + <field-offset>,
allowing to save the heap base add (current Register Allocator
does not allow to save register).
Also with zero base the null check of compressed oop is not
needed. Current code for decoding compressed oops looks like this:

if (<narrow-oop> == NULL)
<wide_oop> = NULL
else
<wide_oop> = <narrow-oop-base> + (<narrow-oop> << 3)

With zero base the code is much simpler:

<wide_oop> = <narrow-oop> << 3

Also if java heap size < 4Gb and it can be moved into low virtual
address space then compressed oops can be used without
encoding/decoding.

Zero based implementation tries to allocated java heap using different
strategies based on the heap size and a platform it runs on.
First, it tries to allocate java heap below 4Gb to use
compressed oops without decoding if heap size < 4Gb.
If it fails or heap size > 4Gb it will try to allocate the heap
below 32Gb to use zero based compressed oops.
If this also fails it will switch to regular compressed oops
with narrow oop base.