RFR: 8342769: HotSpot Windows/gcc port is broken
Julian Waters
jwaters at openjdk.org
Fri Nov 8 09:47:41 UTC 2024
On Thu, 31 Oct 2024 10:09:32 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:
>> I did mean the entire thing. I don't see any point in WIN64 code being in the x86 file when there is an x86_64 file. Of course I had forgotten about the Aarch64 Windows side, so maybe as I said this is really something for a os/windows file rather then `cpu/<arch>` ?
>
> If it's needed on AArch64 too, this should move to something in `os/windows` as David said.
>
> However, judging from the comment in https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/src/hotspot/os/windows/sharedRuntimeRem.cpp#L34-L38 this workaround might not be needed anymore. The minimum version required for Windows-AArch64 is VS2017 (or even VS2019?), and for Windows-X64 apparently VS2022 is used (not sure what the minimum is): https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/make/conf/jib-profiles.js#L1105
>
>
> So maybe this can be removed altogether? Someone needs to check if this assumption is still true today.
>
> Alas I don't have a Windows setup anymore. @karianna who is the local HotSpot Windows expert these days who could have a look at this? 🙂
I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1834028457
More information about the hotspot-dev
mailing list