Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov wrote: >>> > With that said, it is sure as heck confusing! Which also apparently >>> > Microsoft acknowledges by phasing in the term "Windows API". So I agree >>> > that we should try to rename everything currently called "win32" into >>> > "windows". But I'd rather see such a global rename refactoring, that will >>> > also affect the 64-bit Windows platforms, to be done as a separate, >>> > follow-up PR. Are you okay with that? >>> >>> Yes, I completely agree to do such clean up in separate RFE. Please, file >>> one. >> >> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. > > @magicus > Back to my question about > https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 > ? > > I see only few uses of `#ifdef WIN32` in HotSpot which can be replaced with > `#ifdef _WINDOWS`: > > src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 > src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 > > > Note, there are a lot more usages of `WIN32` in JDK libraries native code > which we may consider renaming later. @vnkozlov I have now looked at all ~1800 case-independent hits of "win32" in the `src` directory. All of them is referring to the general Windows API, and not any 32-bit specific code, as far as I can tell from the filename and local context. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455296938
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in >> MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > Okay, I am confuse about `_WIN32` vs `WIN32`. > > You are saying that "_WIN32 is still defined on 64-bit Windows" but you are > removing code guarded by `#ifdef _WIN32` > And our make files defines `WIN32` for all Windows OSs: > https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 @vnkozlov > * There is use of `WIN32` instead of `_WIN32`. > > * There are comments referencing `Win32` which we need to rename to `Windows` > to avoid confusion. > > * There is `class os::win32` in `os_windows.hpp` which is batter to rename to > avoid confusion. Could be done in separate RFE. > > * "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it > is really true, I would still suggest to use our variable `_WINDOWS` for that. Ok. Let's start with being on the same page about the meaning of "win32". This is what Microsoft has to say about it: "The Win32 API (also called the Windows API) is the native platform for Windows apps. [T]he same functions are generally supported on 32-bit and 64-bit Windows." https://learn.microsoft.com/en-us/windows/win32/apiindex/api-index-portal#win32-windows-api I'd say that they are the authoritative source on the subject. :-) So technically there is nothing **wrong** with stuff targeting Windows being called "win32", even if we only support 64-bit Windows going forward. With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? I will, however, do an additional round of checking all the grep hits on "win32" left to double-and-triple check that they indeed are not 32-bit specific. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455104589
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie wrote: >>> With that said, it is sure as heck confusing! Which also apparently >>> Microsoft acknowledges by phasing in the term "Windows API". So I agree >>> that we should try to rename everything currently called "win32" into >>> "windows". But I'd rather see such a global rename refactoring, that will >>> also affect the 64-bit Windows platforms, to be done as a separate, >>> follow-up PR. Are you okay with that? >> >> Yes, I completely agree to do such clean up in separate RFE. Please, file >> one. > >> > With that said, it is sure as heck confusing! Which also apparently >> > Microsoft acknowledges by phasing in the term "Windows API". So I agree >> > that we should try to rename everything currently called "win32" into >> > "windows". But I'd rather see such a global rename refactoring, that will >> > also affect the 64-bit Windows platforms, to be done as a separate, >> > follow-up PR. Are you okay with that? >> >> Yes, I completely agree to do such clean up in separate RFE. Please, file >> one. > > Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. @magicus Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ? I see only few uses of `#ifdef WIN32` in HotSpot which can be replaced with `#ifdef _WINDOWS`: src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455274589
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov wrote: > > With that said, it is sure as heck confusing! Which also apparently > > Microsoft acknowledges by phasing in the term "Windows API". So I agree > > that we should try to rename everything currently called "win32" into > > "windows". But I'd rather see such a global rename refactoring, that will > > also affect the 64-bit Windows platforms, to be done as a separate, > > follow-up PR. Are you okay with that? > > Yes, I completely agree to do such clean up in separate RFE. Please, file one. Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455256779
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote: > Can we get rid of `JNICALL` too, please? That we can never do, since it is part of jni.h which are imported in likely millions of JNI projects. But we can replace it with an empty define. And we can document it as not needed anymore, and start removing it from our own call sites. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455142166
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie wrote: > With that said, it is sure as heck confusing! Which also apparently Microsoft > acknowledges by phasing in the term "Windows API". So I agree that we should > try to rename everything currently called "win32" into "windows". But I'd > rather see such a global rename refactoring, that will also affect the 64-bit > Windows platforms, to be done as a separate, follow-up PR. Are you okay with > that? Yes, I completely agree to do such clean up in separate RFE. Please, file one. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455239110
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote: >>> Can we get rid of `JNICALL` too, please? >>> >>> Or would that change be too big? >> >> There's >1000 in java.base, lots more elsewhere, so it would be a lot of >> files and would hide the core changes. So maybe for a follow-up PR that does >> the one thing. > >> > Can we get rid of `JNICALL` too, please? >> > Or would that change be too big? >> >> There's >1000 in java.base, lots more elsewhere, so it would be a lot of >> files and would hide the core changes. So maybe for a follow-up PR that does >> the one thing. > > Yeah. I count >8000 places in total... > > Maybe just define JNICALL to be empty in jni_md.h for now. @tstuefe Your comment reminded me of another important cleanup, to remove `__stdcall` (and `_stdcall`, an accepted but not recommended variant) from the code base. This only has meaning on 32-bit Windows. Furthermore, when searching for this, I found additional code that is looking for symbol names of "__stdcall format", i.e. `@`. This is not needed anymore. I'll delete it where I find it, but there might be other places that I'm missing. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455215002
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev wrote: >> make/modules/jdk.accessibility/Lib.gmk line 57: >> >>> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) >>> 56: >>> 57: >>> ## >> >> Most of the desktop related changes are related to Assistive Technologies >> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the >> 64 bit JDK, but I'd like to be sure I am not forgetting something. >> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an >> AT, so traditionally we provided both 32 and 64 bit versions because we >> don't control that AT. >> >> So I would like Alex Zuev to review these changes. For whatever reason his >> git hub handle doesn't seem to be found. I think it is something like >> @azuev-java > > We built 32-bit dll in order to provide access to the accessibility > interfaces for the legacy 32-bit software that can not load the 32-bit code. > We abandoned this practice since at least Java 11 and we had no complaints > about it ever since. All the relevant accessibility software we are aware of > have 64-bit executable and only support 32-bit operating systems with the > legacy versions that are not recommended to use with modern OSes. I do not > see any problem in abandoning 32-bit code in windowsaccessbridge.dll. @azuev-java Thanks! I have one more question for you: To avoid risking breaking any compatibility, the file generated from the source code in `windowsaccessbridge` is still compiled into a file called `windowsaccessbridge-64.dll`. This is a bit unusual, and requires a quirk in the build system -- normally we assume there is a 1-to-1 relationship between the directory containing the native library source code, and the generated `.dll` file. Is this file exposed to external parties, that rely on a specific name? Or is it just used internally by the JDK, so we could rename it to `windowsaccessbridge.dll`, and just update our reference to it? - PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827989703
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes wrote: >> The deletion is apparently working, else we'd be getting build failures. So >> while there are some potential issues and opportunities for further cleanup >> in >> this file, I think they ought to be addressed separately from this PR. See >> new https://bugs.openjdk.org/browse/JDK-8343530. > > There is a difference between "working" and not causing a build failure. I > suspect none of that code is actually needed these days, but I'm not sure. As > deleting the entire section goes beyond deleting 32-bit code, I would expect > it to be partially restored in this PR and then cleaned up in a later PR. "using namespace std;" in a header is generally a bad idea. It brings all kinds of stuff into scope, potentially leading to name conflicts down the road. And seems like a strange thing to do only for windows. Removal of the strdup macro is covered by the NONSTDC macros added at build time. It's not a 32bit cleanup either, and you suggested it. Removal of [u]intptr_t definitions will cause a build failure if it results in them being undefined. And getting an incorrect definition from elsewhere seems implausible. I claim this all just isn't needed anymore and can be removed in this PR, just as you suggested for the strdup macro. The 64bit definitions could be added back in this PR (to be removed later by JDK-8343530), but that just seems like useless churn. So I'm happy with the current removal of the entire chunk. - PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827469354
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman wrote: > > Can we get rid of `JNICALL` too, please? > > Or would that change be too big? > > There's >1000 in java.base, lots more elsewhere, so it would be a lot of > files and would hide the core changes. So maybe for a follow-up PR that does > the one thing. Yeah. I count >8000 places in total... Maybe just define JNICALL to be empty in jni_md.h for now. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454234501
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize This is a very nice reduction in complexity. As I wrote before, removing windows 32-bit removes the need for calling convention definition, so I think we could get rid of JNICALL in addition to anything stdcall/fastcall related. I had a close look at hotspot os and os_cpu changes, cursory glances at other places, all looked fine. - PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412592195
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 09:21:52 GMT, Thomas Stuefe wrote: > Can we get rid of `JNICALL` too, please? > > Or would that change be too big? There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454201348
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Can we get rid of `JNICALL` too, please? Or would that change be too big? - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454188077
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 09:00:59 GMT, Kim Barrett wrote: >> src/hotspot/share/adlc/adlc.hpp line 43: >> >>> 41: >>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ >>> 43: #ifdef _WIN32 >> >> As this is a synonym for `_WINDOWS` it is not obvious this deletion is >> correct. > > The deletion is apparently working, else we'd be getting build failures. So > while there are some potential issues and opportunities for further cleanup in > this file, I think they ought to be addressed separately from this PR. See > new https://bugs.openjdk.org/browse/JDK-8343530. There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. - PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827408129
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in >> MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > src/hotspot/share/adlc/adlc.hpp line 43: > >> 41: >> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ >> 43: #ifdef _WIN32 > > As this is a synonym for `_WINDOWS` it is not obvious this deletion is > correct. The deletion is apparently working, else we'd be getting build failures. So while there are some potential issues and opportunities for further cleanup in this file, I think they ought to be addressed separately from this PR. See new https://bugs.openjdk.org/browse/JDK-8343530. - PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827395928
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Changes requested by dholmes (Reviewer). src/hotspot/share/adlc/adlc.hpp line 43: > 41: > 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ > 43: #ifdef _WIN32 As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. - PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412031267 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827135809
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 18:44:02 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in >> MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > make/modules/jdk.accessibility/Lib.gmk line 57: > >> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) >> 56: >> 57: >> ## > > Most of the desktop related changes are related to Assistive Technologies > I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 > bit JDK, but I'd like to be sure I am not forgetting something. > The point being windowsaccessbridge.dll is not loaded by the JDK, but by an > AT, so traditionally we provided both 32 and 64 bit versions because we don't > control that AT. > > So I would like Alex Zuev to review these changes. For whatever reason his > git hub handle doesn't seem to be found. I think it is something like > @azuev-java We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll. - PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826520980
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Looks good, subject to addressing @vnkozlov comments. - Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2410940653
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize make/modules/jdk.accessibility/Lib.gmk line 57: > 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) > 56: > 57: > ## Most of the desktop related changes are related to Assistive Technologies I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java - PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826177047
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize 1. There is use of `WIN32` instead of `_WIN32`. 2. There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion. 3. There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE. 4. "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that. - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452335968
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 >> Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. >>> This port was [deprecated for removal in JDK >>> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >>> future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in > MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Okay, I am confuse about `_WIN32` vs `WIN32`. You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32` And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 - PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452349567
Re: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17]
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 > Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. >> This port was [deprecated for removal in JDK >> 21](https://openjdk.org/jeps/449) with the express intent to remove it in a >> future release. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers - Remove windows-32-bit code in CompilerConfig::ergo_initialize - Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/fe8ba082..68d6fe5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15-16 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744
