[aarch64-port-dev ] [8u] RFR: Revert differences against upstream 8u

[Andrew Haley]

On 19/02/2021 09:47, Andrew Haley wrote:
> On 18/02/2021 18:56, Aleksey Shipilev wrote:
>> On 2/18/21 7:41 PM, Andrew Hughes wrote:
>>> On 19:30 Thu 18 Feb     , Aleksey Shipilev wrote:
>>>> changeset:   8867:af37ee789a9c
>>>> user:        aph
>>>> date:        Thu May 05 14:14:21 2016 +0000
>>>> summary:     AArch64 support for Shenandoah.
>>>
>>> Right, upstream has '%' because it's the pre-Shenandoah sources.
>>> It was later removed in aarch64/shenandoah-jdk8u:
>>>
>>> https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/af37ee789a9c#l10.14
>>>
>>> Removing it is the right thing, no?
>>
>> I don't see how.
>>
>> 8u upstream has it with "%":
>>  
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/3d2970e26c36/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp#l1723
>>
>> ...and it still has "%r0" in the line that is not affected by Shenandoah at all:
>>  
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/3d2970e26c36/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp#l1744
>>
>> ...and the same shape remains thorough JDK 11 -> JDK 17.
>>
>> It is a typo in the initial Shenandoah 8u sources, plain and simple, should be reverted to upstream 
>> state. Moreover, this is a _comment line_, it does not even affect the product code.
> 
> It really doesn't matter one way or the other. It doesn't affect
> the sense of the comment.

Found its origin:

# HG changeset patch
# User aph
# Date 1366383259 -3600
#      Fri Apr 19 15:54:19 2013 +0100
# Branch aarch64_c1
# Node ID 75d074c0bb0e3573f9d120a95fdf30d1fc247170
# Parent  0ee05f165e3b94e49185e70d5f52eb1a8b433d79
Much new c1 code generation:
Object allocation
Array allocation
Correct codegen for int add/sub/shift
Arraycopy
volatile load & store
c2i adapters
Native wrappers

-    // Load (object->mark() | 1) into swap_reg %rax
-    __ orptr(swap_reg, Address(obj_reg, 0));
+    // Load (object->mark() | 1) into swap_reg %r0
+    __ ldr(rscratch1, Address(obj_reg, 0));
+    __ orr(swap_reg, rscratch1, 1);

So the "%rax" was in the x86 code the AArch64 port is based on, but
it doesn't make much sense there either. And at some point someone,
perhaps me, "cleaned it up", but not on mainline. Oh well.

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