[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 hotspot-dev
mailing list