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

[Nick Gasson]

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

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?

I'll do some testing with AOT later.


Thanks,
Nick