[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