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

Pengfei Li (Arm Technology China) Pengfei.Li at arm.com
Mon Nov 18 09:58:11 UTC 2019


Hi Andrew,

> I see
> 
>   if (use_XOR_for_compressed_class_base) {
>     if (CompressedKlassPointers::shift() != 0) {
>       eor(dst, src, (uint64_t)CompressedKlassPointers::base());
>       lsr(dst, dst, LogKlassAlignmentInBytes);
>     } else {
>       eor(dst, src, (uint64_t)CompressedKlassPointers::base());
>     }
>     return;
>   }
> 
>   if (((uint64_t)CompressedKlassPointers::base() & 0xffffffff) == 0
>       && CompressedKlassPointers::shift() == 0) {
>     movw(dst, src);
>     return;
>   }
> 
>   ... followed by code which does use r27.
> 
> Do you ever see r27 being used? If so, I'd be interested to know how this gets
> triggered and what command-line arguments you use. It's rather inefficient.

I think you're right. I tried hard with various VM options but still failed to
get the code after this part triggered. The worst case I've ever found is that
the encoding/decoding returns at if block
  if (((uint64_t)CompressedKlassPointers::base() & 0xffffffff) == 0
      && CompressedKlassPointers::shift() == 0) { ... }

By browsing the code, I found this is caused by a metaspace reservation trick
that always tries to make AArch64 metaspace 4G-aligned. [1]

If we do have the confidence that r27 won't be used for class pointers, I will
remove UseCompressedClassPointers in my if condition. Another question, shall
we clean up the (almost) dead code which uses r27 for encoding/decoding class
pointers?

[1] http://hg.openjdk.java.net/jdk/jdk/file/7bdc4f073c7f/src/hotspot/share/memory/metaspace.cpp#l1048

--
Thanks,
Pengfei



More information about the aarch64-port-dev mailing list