narrow_klass_shift is nonzero on jdk9...
Andrew Haley
aph at redhat.com
Fri Jan 23 16:48:16 UTC 2015
... when it doesn't need to be.
The reason for this is that we allocate the heap at the end of the
lower 4*G region and we allocate the metaspace immediately after the
heap, so we always need a nonzero narrow_klass_shift because
narrow_klass_base is not less than 32 bits.
If I set HeapBaseMinAddress=2g it's fine.
The code which puts the heap right at the end of the lower 4*G region
is quite deliberate:
// Return specified base for the first request.
if (!FLAG_IS_DEFAULT(HeapBaseMinAddress) && (mode == UnscaledNarrowOop)) {
base = heap_base_min_address_aligned;
// If the total size is small enough to allow UnscaledNarrowOop then
// just use UnscaledNarrowOop.
} else if ((total_size <= OopEncodingHeapMax) && (mode != HeapBasedNarrowOop)) {
if ((total_size <= UnscaledOopHeapMax) && (mode == UnscaledNarrowOop) &&
(Universe::narrow_oop_shift() == 0)) {
// Use 32-bits oops without encoding and
// place heap's top on the 4Gb boundary
base = (UnscaledOopHeapMax - heap_size);
Why do we do this? I carefully set HeapBaseMinAddress in the AArch64
back end to a sensible value which would in many cases get me a zero
narrow_klass_shift, but this code ignores the default.
Thanks,
Andrew.
More information about the hotspot-dev
mailing list