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

[Anton Kozlov]

The cleanup in cpu/aarch64/vm_version may be considered as a work in general or
a work toward landing patches, depends on the terminology :)

Since we've are on par in understanding, I've created JDK-8253015 and drafted a
patch[1] consisting mostly of what we have discussed.  Would it be OK if I make
a formal review request (now PR) for integration? I mean, it will create some
burden for you if you have made steps in this direction as well.

After the patch the common and linux code do not use code generation. But it is
still possible in os-specific code, like [2]. It returns memory to the code
cache, but as far as I can see the block ends up in a free-list, creating small
fragmentation. So I would stick to a static code if possible or would use a
buffer on a stack if it has execute permission. I hope changes for
windows-aarch64 on top of [1] will be straightforward. But unfortunately, I
don't have a setup to test that. So I hope to get your review, now or after
the possible PR.

Thanks,
Anton

[1] https://github.com/openjdk/jdk/compare/master..AntonKozlov:8253015#diff-914c0b9083f9d7ee2d08f5dbd3c54ebe
[2] https://github.com/AntonKozlov/jdk/compare/8253015..8253015-codegen

On 08.09.2020 22:09, Ludovic Henry wrote:
> 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
>