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