[aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support

[Ludovic Henry]

Hi Anton,

You can find the diff at https://gist.github.com/luhenry/d981f5fe7e9f1a1ad8cd3292b5e75cc4 (we are in the process of upstreaming it).

> 1. The linux part of feature detection should probably go to os_cpu/xxx/vm_version_xxx.cpp.

It probably should indeed. I'd do the work for the macOS-AArch64 port, and I would adapt the windows-AArch64 port whichever lands first.

> 2. CPU features detection stub [1] for some reason takes 550 bytes (and is allocated permanently in the code cache), constructs a frame, and probably can be replaced with just inline assembly at least for Linux.

I agree, especially since `ctr_el0` is not even accessible on Windows. I'm happy to go for inline assembly or a dedicated assembly file. We need to keep it in `os_cpu` (especially for inline assembly) as it will need to be different for Windows at least (even for macOS, since the compiler is different and some platform specifics quirks).

> 3. dcpop feature is taken from /proc/cpuinfo[2], although it is also there in HWCAP[3].

There is no equivalent of /proc/cpuinfo on Windows, and we can only rely on `IsProcessorFeaturePresent`. I would make sure to keep that check in `os_cpu` for the same reason as above.

> 4. I'm a bit concerned about Feature_Flags[4] implicitly mirrors of Linux HWCAP. I think some code (e.g assert) should provide a hint about mapping. For example, HWCAP_ATOMIC implicitly mapped to CPU_LSE. As a note, Feature_Flags had also leaked into Graal, which should also be considered.

In the case of Feature_Falgs, I would not implicitly define Feature_Flags with HWCAP_*, so I would make sure that `_features` is not simply assigned with the result of `getauxval`. I would also do the mapping HWCAP -> Feature_Flags in the Linux-AArch64 specific code, so that HWCAP doesn't have to leak into the Windows or macOS codebase.

> I'm asking to avoid duplicating efforts. If you have done some significant work for vm_version that you're not ready to share yet, then OK, there is no rush. Otherwise, I can try to do something with these and anything else that may jump out after some work. In that case, the success criteria will be a better separation of common and Linux code, which should also simplify the Windows-aarch64 patch.

All our Windows-AArch64 changes have been made public (through upstreaming it directly to jdk/jdk or by publishing webrevs), and we have no major work in progress, other than getting the current patches to land.

I would be very happy to follow along what you're doing on a public repository, and contribute whatever we can. As we discussed offline last week, we are working on our end to publish what we have so far.

Thank you,
Ludovic