OpenJDK extension to AArch64 and Windows

[Andrew Haley]

On 24/06/2020 17:40, Monica Beckwith wrote:
> Hello OpenJDK community,
>
> As the project lead here @Microsoft, I am pleased to share that we
> have been working towards a Windows addition to the OpenJDK AArch64
> port. We are very thankful to all that have contributed to the
> Linux+aarch64 and Windows+x86-64. Both these codebases came to our
> rescue on numerous occasions.
>
> Support status: We have successfully ported C2 and can build the
> server release (cross-compiled environment)

> Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC)
> Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005.
> Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238
> Webrevs:
> `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/  &

This looks basically OK, but the use of uint64_t doesn't read well in
aarch64.ad. (For what it's worth, the type used internally in HotSpot
for $$constant is actually intptr_t.)

3130   enc_class aarch64_enc_mov_imm(iRegL dst, immL src) %{
3131     C2_MacroAssembler _masm(&cbuf);
3132     Register dst_reg = as_Register($dst$$reg);
3133     uint64_t con = (uint64_t)$src$$constant;

Here, the type of the register is iRegL, so con could be a julong,
not a uint64_t.

In general the easiest way to fix aarch64.ad is probably

long -> jlong
unsigned long -> julong
u_int64_t -> uint64_t

But not always everywhere. Here, the arg is an address offset:

-void Assembler::adrp(Register reg1, const Address &dest, unsigned long &byte_offset) {
+void Assembler::adrp(Register reg1, const Address &dest, uint64_t &byte_offset) {
   ShouldNotReachHere();
 }

uintptr_t would do here.

The coments in aarch64.ad like this one:

-  format %{ "mov $dst, $src\t# long" %}
+  format %{ "mov $dst, $src\t# int64_t" %}

refer to a *Java type*. It shouldn't be changed.

Rather than keep bouncing this back and forth until I'm statisfied,
which would be boring for both of us, if you like I'll replace all of
the bare "long" and "unsigned long" with the appropriate portable
types. Do you want me to do that?

Thanks.

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