Question about ccs reservation, CDS and aarch64 specifics

Nick Gasson nick.gasson at arm.com
Mon Apr 20 07:00:51 UTC 2020


Hi Thomas,

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

Yes. Previously if the alignment of the compressed class base was such
that it couldn't use EOR or MOVK to decode, it would fall back to a
generic shift+add using the compressed oop base register, rheapbase, as
temporary. This works because you can call reinit_heapbase to restore
the original value of rheapbase.

The problem with this is that it generates ~2x the instructions of the
other decoding modes, which breaks some size assertions elsewhere in
addition to just being inefficient. Additionally if compressed oops are
not enabled we want to be able to reuse rheapbase as a general
allocatable register, but in that case we can't use it as temporary for
decoding class pointers.

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

Yes I think this works.


Thanks,
Nick


More information about the hotspot-runtime-dev mailing list