Question about ccs reservation, CDS and aarch64 specifics

[Thomas Stüfe]

Hi Nick,

thanks for your explanations!

This may be a stupid question, but you rheapbase was used for both
en/decoding compressed oops and compressed class pointers, right? Just was
confused by the name.

I would like to abstract the logic of allocating "good" memory for ccs away
from the shared code into platform dependent files (e.g.
metaspace_aarch64.cpp) so that each platform can cleanly implement whatever
they feel is right. Ages ago we had a similar thing for allocating heap
memory on AIX, that worked quite well.

So, if I were to give you these prototypes:

+  // Given a size, reserve a space anywhere, suitable to be used as
backing storage for ccs. The return
+  // address will be the base address for encoding/decoding compressed
Klass pointers.
+  // Depending on the platform, this function may allocate anywhere or
attempt platform specific optimized
+  // placement.
+  // If size is not aligned to Metaspace::reserve_alignment it will be
corrected, so the returned space may be larger.
+  // On failure an unreserved space is returned.
+  static ReservedSpace reserve_compressed_class_space_anywhere(size_t
size);
+
+  // Given a size and an address p, reserve a space at address p, suitable
to be used as backing storage for ccs.
+  // If p is not a suitable base address for encoding/decoding compressed
Klass pointers, function will fail.
+  // Attach point has to be aligned to metaspace reserve alignment.
+  // If size is not aligned to Metaspace::reserve_alignment it will be
corrected, so the returned space may be larger.
+  // On failure an unreserved space is returned.
+  static ReservedSpace reserve_compressed_class_space_at(address p, size_t
size);

this should be enough to implement platform dependent ccs allocation, right?

Cheers, Thomas

On Mon, Apr 20, 2020 at 4:56 AM Nick Gasson <nick.gasson at arm.com> wrote:

> On 04/18/20 14:26 pm, Thomas Stüfe wrote:
> > Just occurred to me that aarch64 also relies on SharedBaseAddress being
> 4G
> > aligned. The default is 32G so it works out. If you modify it with
> > -XX:SharedBaseAddress, looks like the setting is ignored when the value
> is
> > not usable.
> >
>
> Yes that's correct, it's treated as a hint on AArch64 since
> 8234794. Because MacroAssembler::{decode,encode}_klass cannot implement
> arbitrary base + (src << shift) without an additional temporary register
> that isn't always available when it's called. It seems better to
> constrain the possible base addresses than reserve a dedicated
> compressed class base register.
>
> All the different compressed class decoding modes should now be covered
> by the jtreg tests. So if you have access to an AArch64 machine, running
> these should be sufficient to prevent regressions. I'm also happy to
> help with testing.
>
>
> Thanks,
> Nick
>