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

[Nick Gasson]

>> >
>> > 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.
>
> When CDS is enabled, the compressed klass encoding shift is set to
> LogKlassAlignmentInBytes with the intend for AOT compatibility. AOT
> requires LogKlassAlignmentInBytes (3) as the shift.
>

Yes, in AOTGraalHotSpotVMConfig.java we have:

  // AOT captures VM settings during compilation. For compressed oops this
  // presents a problem for the case when the VM selects a zero-shift mode
  // (i.e., when the heap is less than 4G). Compiling an AOT binary with
  // zero-shift limits its usability. As such we force the shift to be
  // always equal to alignment to avoid emitting zero-shift AOT code.
  CompressEncoding vmOopEncoding = super.getOopEncoding();
  aotOopEncoding = new CompressEncoding(vmOopEncoding.getBase(), logMinObjAlignment());
  CompressEncoding vmKlassEncoding = super.getKlassEncoding();
  aotKlassEncoding = new CompressEncoding(vmKlassEncoding.getBase(), logKlassAlignment);

I get why AOT needs to set the shift for compressed OOPs, but for
compressed class pointers the maximum class space size is 3G so the
shift is only useful to allow a zero base. For AOT+CDS the default class
space load address is 0x800000000 (32G) which is above the limit where a
zero base is possible. So I think it would be better if AOT and CDS used
a zero shift by default, as on AArch64 and X86 at least, we generate
less efficient code when both the shift and base are non-zero. Using
logKlassAlignment above works well for non-CDS, as it allows the class
space to mapped at a low address with zero base.

Maybe aotKlassEncoding could be set from the current VM settings
instead?


Thanks,
Nick