[aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable

Andrew Haley aph at redhat.com
Mon Dec 2 15:34:33 UTC 2019


On 12/2/19 7:55 AM, Nick Gasson wrote:
> On 29/11/2019 18:10, Andrew Haley wrote:
>>> How about we exit with a fatal error if we can't find a suitably aligned
>>> region? Then we can remove the code in decode_klass_non_null that uses
>>> R27 and this patch is much simpler. That code path is poorly tested at
>>> the moment so it seems risky to leave it in. With a hard error at least
>>> users will report it to us so we can fix it.
>>
>> That is starting to sound very attractive. With a 64-bit address space I'm
>> finding it very hard to imagine a scenario in which we don't find a
>> suitable address. I think AOT-compiled code would still be OK, because it
>> generates different code, but we'd have to do some testing.
>>
> 
> There's another little wrinkle: even after updating the shared metaspace 
> to use the search algorithm to find a 4G-aligned location, we can still 
> end up with something like:
> 
> CompressedKlassPointers::base() => 0x1100000000
> CompressedKlassPointers::shift() => 3
> 
> (The shift is always set to LogKlassAlignmentInBytes when CDS is on.)

I remember that. I don't know why; it's not much use to us on AArch64.

> Here we can't use EOR because 0x1100000000 doesn't fit in the immediate, 
> and we can't use MOVK because the shift is non-zero.
> 
> I think the solution is to adjust the algorithm to search in increments 
> of (4 << LogKlassAlignmentInBytes)*G once we hit 32G (the point at which 
> we can no longer use a zero base). Then we can decode like this:
> 
>      const uint64_t shifted_base =
>        (uint64_t)CompressedKlassPointers::base() >> 
> CompressedKlassPointers::shift();
>      guarantee((shifted_base & 0xffffffff) == 0, "compressed class base 
> bad alignment");
> 
>      if (dst != src) movw(dst, src);
>      movk(dst, shifted_base >> 32, 32);
> 
>      if (CompressedKlassPointers::shift() != 0) {
>        lsl(dst, dst, LogKlassAlignmentInBytes);
>      }
> 
> What do you think?

Could work, but can you also try disabling the shift with CDS? It doesn't do
us much good and it bloats code.

-- 
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-compiler-dev mailing list