[aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation

Andrew Haley aph at redhat.com
Wed Apr 29 14:21:44 UTC 2020


On 4/28/20 3:54 PM, Thomas Stüfe wrote:
> These two methods should give the platform enough control to implement
> their own scheme for optimized class space placement without bothering any
> shared code about it.

There's still something I don't like. If we have a compressed class space
in the lower 32G but above 4G, we do this:

    // Otherwise we attempt to use a zero base if the range fits in lower 32G.
    if (end <= (address)ClassEncodingMetaspaceMax) {
      base = 0;
    } else {
      base = addr;
    }

    // Highest offset a Class* can ever have in relation to base.
    range = end - base;

    // We may not even need a shift if the range fits into 32bit:
    const uint64_t UnscaledClassSpaceMax = (uint64_t(max_juint) + 1);
    if (range < UnscaledClassSpaceMax) {
      shift = 0;
    } else {
      shift = LogClassAlignmentInBytes;
    }

... which means that we end up with zero base, shifted compressed
class pointers, *despite the fact* that we carefully chose a
nicely-aligned compressed class base we could encode efficiently.

I guess this code above is really optimized for x86; it certainly
seems to prefer shifts to offsets, which makes sense on that part. It
doesn't make much difference (if any) for AArch64, I admit, but it is
odd.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the aarch64-port-dev mailing list