RFR: 8342769: HotSpot Windows/gcc port is broken
Bernhard Urban-Forster
burban at openjdk.org
Thu Oct 31 10:12:29 UTC 2024
On Tue, 22 Oct 2024 09:43:54 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> You mean the entire custom frem and drem implementation unique to x64 Windows, or just this block of constants here? These constants are used by the custom Windows implementation, so they have to be in the same file. Moving the entire definition for Windows x64 to sharedRuntime_x86_64.cpp seems to be duplicating code even more, and I still don't know whether this is the right solution. It may be that this custom implementation may not be needed anymore and should be removed, which is why I left it in the sharedRuntime_x86.cpp file for the time being
>
> 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? 🙂
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1824202682
More information about the hotspot-dev
mailing list