Sending to public.
Fixed 6791178: Specialize for zero as the compressed oop vm heap base
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
+ ( << 3) + .
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 (,
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 ( == NULL)
= + ( << 3)
These checks and branches are killing the performance
of compressed oops. With zero base the code is much simpler:
= << 3
Also if heap size < 4Gb and it can be moved into low virtual
address space then compressed oops can be used without
This implementation tries to allocated java heap using different
strategies based on the heap size and a platform it runs on.
It tries first 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.
The code is implemented for all GC. I added the code for G1 also
but currently G1 does not support compressed oops.
Fixed serviceability agent and dtrace to access new VM variables.
Reviewed by: never, twisti, jcoomes, coleenp
Fix verified (y/n): y
JPRT, JDK build, nsk sajdi (with compressed oops on by default)