narrow_klass_shift is nonzero on jdk9...
aph at redhat.com
Fri Jan 23 17:46:08 UTC 2015
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?
More information about the hotspot-dev