max heap size for compressed oops

[Andrew Haley]

On 12/09/2015 04:04 PM, Matthias Wahl wrote:
> Do you know any reason for limiting the heap size to 30.5 GB instead of
> 32 GB?

The interesting thing you can do is use -XX:+PrintAssembly and have a
look.  My guess is that it has to do with zero-based compressed OOPs:
if you can use zero as the base pointer you don't have to dedicate a
register to the job and the compressing/decompressing code is faster.

A narrow OOP is computed by

  oop_address == 0  ? 0 : (oop_address - heap_base) >> shift

The OOP at 0 is a null, of course.

If the heap base is zero, you can encode an OOP with a single
shift instruction:

     lsr x0, x0, #3

But if the heap base is not zero, encoding an OOP gets nasty:

     subs x0, x0, xheapbase
     csel x0, x0, xzr, cs
     lsr  x0, x0, #3

Here there are three instructions, one of them conditional.  In the
commonest case most modern processors can do the shifting in parallel
with some other operation, so the cost of compressed OOPs is often
zero as long as the heap base is zero.  But there's no way that the
three instructions used encoding an OOP with a nonzero heap base are
gong to cost nothing.

So why is there a difference between 30.5G and 32G?  Because in
practice the JVM sits in the bottom 1.5G or so of memory and the heap
is immediately above it, so the heap base for compressed OOPs can be
zero.

Does that make sense?

Andrew.