[aarch64-port-dev ] Question about ccs reservation, CDS and aarch64 specifics

[Thomas Stüfe]

On Mon, Apr 20, 2020 at 8:35 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> 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?
>
>
(Specifically, leaving the part of "checking request address if it fits
zero based encoding" out, since the odds that the caller knows a low
address which just happens to be free on my platforms are low; if zero
based is important, platform probably knows better and can come up with a
low address on its own.)



> 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
>>
>