[aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support
luhenry at microsoft.com
Tue Sep 8 19:09:18 UTC 2020
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  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, although it is also there in HWCAP.
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 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.
More information about the aarch64-port-dev