narrow_klass_shift is nonzero on jdk9...

[Andrew Haley]

Hi,

On 01/23/2015 05:08 PM, Coleen Phillimore wrote:
> 
> Allocating this compressed class space is unfortunately complicated.  I 
> think you're looking at an old version of the code though, Goetz has 
> changed this and moved it to virtualspace.cpp.

Okay.  This is a fairly recent cut of JDK9, but we are a bit behind.

> The compressed class space is allocated above the heap because we want 
> the java heap to have the most favorable compression algorithm.
> 
> The code also has a special case so that for zero-based compressed oops; 
> it saves space for the compressed class space to also get zero-based 
> compressed class pointers.  Decoding klasses without a base is better 
> than decoding without a shift.

That's architecture-dependent, I would have thought.  On the AArch64
port it can be somewhat better to have a nonzero base.  (We just OR
a bit or two into the register to decode.)

> The code doesn't try to fit both compressed oops and compressed
> class pointers in the lower 4G.  It's generally improbable since the
> compressed class space is 1G size (because growing it is not
> supported atm) and doing so generally pushes the java heap over the
> 4*G size.  Although I have to admit that HeapBaseMinAddress still
> mystifies me (for linux).

Ah, okay, that makes sense.  The application I'm running sets
MaxHeapSize to 1*G.  Wouldn't it at least be worth trying to allocate
the metadata below the heap after the heap has been allocated?

Thanks,
Andrew.