[EXTERNAL] Re: Proposed JEP - Deprecate the Windows x86-32 Port

Wed Mar 29 16:03:20 UTC 2023

Thanks. Onward!

Alex

On 3/29/2023 12:53 AM, George Adams wrote:
> Hi Alex,
> 
> Thanks so much for your feedback,
> 
> I’ve gone ahead and pushed those proposed changes by Bruno to the JEP.
> 
> Thanks
> 
> George Adams
> 
> *From: *Bruno Borges <Bruno.Borges at microsoft.com>
> *Date: *Wednesday, 29 March 2023 at 02:00
> *To: *Alex Buckley <alex.buckley at oracle.com>, jdk-dev at openjdk.org 
> <jdk-dev at openjdk.org>, George Adams <George.Adams at microsoft.com>
> *Subject: *Re: [EXTERNAL] Re: Proposed JEP - Deprecate the Windows 
> x86-32 Port
> 
> Hey Alex,
> 
> Thanks for the feedback!
> 
> I went ahead and proposed changes based on your comments for George to 
> review/merge:
> 
> https://github.com/microsoft/openjdk-proposals/pull/11 
> <https://urldefense.com/v3/__https://github.com/microsoft/openjdk-proposals/pull/11__;!!ACWV5N9M2RV99hQ!JwB7HYDZy1xG-BhDnmuxIuK0f37WnIbIQia8jZMewF_-5HelXxVb8JLlAPLoi4kJeGEbR0Aa6DI-umo5Yq8ytDmAgrva$>
> 
> *From: *Alex Buckley <alex.buckley at oracle.com>
> *Date: *Tuesday, March 28, 2023 at 4:43 PM
> *To: *jdk-dev at openjdk.org <jdk-dev at openjdk.org>, George Adams 
> <George.Adams at microsoft.com>, Bruno Borges <Bruno.Borges at microsoft.com>
> *Subject: *Re: [EXTERNAL] Re: Proposed JEP - Deprecate the Windows 
> x86-32 Port
> 
> One last try to reach George Adams with comments on his JEP.
> 
> The mail below is also linked in a comment from the JEP (JDK-8303167).
> 
> Alex
> 
> On 3/3/2023 9:53 AM, Alex Buckley wrote:
>> Hi George,
>> 
>> A couple of stylistic points on the JEP:
>> 
>> 1. Goals and Non-Goals usually appear before Motivation, e.g., as done 
>> in JEP 362.
>> 
>> 2. In Alternatives, there is a paragraph about "It is also known that 
>> 32-bit JVMs on Windows ...". This paragraph describes what a user could 
>> do if this JEP proceeds, but Alternatives is usually about what the JEP 
>> author could do instead the thing they just spelled out in the Description.
>> 
>> I recommend moving the paragraph to Risks & Assumptions, where you 
>> already have a user story about WOW64. You could say something like the 
>> text below. I made numerous edits for tone (I thought "in the wild" was 
>> a bit flippant) and for clarity (there was an "older" and "newer" theme 
>> going on that I thought unnecessary) and most importantly to spell out 
>> the assumption.
>> 
>> -----
>> It is known that 32-bit JVMs on Windows are still used due to 
>> integration with 32-bit DLLs. These users cannot migrate directly to 
>> 64-bit JVMs, because a 64-bit process on Windows cannot load a 32-bit 
>> DLL. This JEP assumes that these users can continue to run a 32-bit JVM 
>> to integrate with these native libraries, and expose their functionality 
>> over some form of remote API that can be consumed by code in a 64-bit 
>> JVM, within the same environment.
>> -----
>> 
>> Alex
>> 
>> On 3/3/2023 2:43 AM, George Adams wrote:
>>> Thank you so much for the feedback that everyone has provided so far. 
>>> I have pushed a handful of changes to the JEP draft to help clarify 
>>> some points. Most notably, this JEP does not intend to deprecate any 
>>> other x86_32 ports.
>>>
>>> Thanks
>>>
>>> George Adams
>>>
>>> *From: *Glavo <zjx001202 at gmail.com>
>>> *Date: *Wednesday, 1 March 2023 at 12:08
>>> *To: *Alan Bateman <Alan.Bateman at oracle.com>
>>> *Cc: *George Adams <George.Adams at microsoft.com>, 
>>> jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
>>> *Subject: *[EXTERNAL] Re: Proposed JEP - Deprecate the Windows x86-32 
>>> Port
>>>
>>>
>>>
>>> You don't often get email from zjx001202 at gmail.com. Learn why this is 
>>> important <https://aka.ms/LearnAboutSenderIdentification 
> <https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!ACWV5N9M2RV99hQ!JwB7HYDZy1xG-BhDnmuxIuK0f37WnIbIQia8jZMewF_-5HelXxVb8JLlAPLoi4kJeGEbR0Aa6DI-umo5Yq8ytCMxl-Yu$>>
>>>
>>>
>>>
>>> I have seen many Intel Celeron N/J machines with memory <4GiB. 
>>> Although x86-32 is old, its non-heap memory footprint is lower, so it 
>>> works better under resource constraints.
>>>
>>> And although Windows 11 does not provide 32-bit images, as far as I 
>>> know, Microsoft does not plan to give up support for running 32-bit 
>>> programs on 64-bit systems.
>>>
>>> 32-bit programs are still an important part of Windows, a large number 
>>> of programs are still 32-bit.
>>>
>>> For a considerable number of client applications, upgrading to 64-bit 
>>> has only negative benefits.
>>>
>>> They only need a little memory and are not sensitive to performance.
>>>
>>> What will 64-bit bring to them? Higher resource consumption and poor 
>>> compatibility (cannot run on x86-32 or Windows 10 on Arm systems)
>>>
>>> I know that maintaining a port requires a lot of manpower, so I can't 
>>> ask you to do anything. But I really hope it will continue to be 
>>> maintained.
>>>
>>> On Tue, Feb 28, 2023 at 3:15 AM Alan Bateman <Alan.Bateman at oracle.com 
>>> <mailto:Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>> wrote:
>>>
>>>     On 27/02/2023 11:04, George Adams wrote:
>>>
>>>         Hi all,
>>>
>>>         I’ve been asked to socialize my proposed JEP to deprecate the
>>>         Windows x86-32 port on this mailing list.
>>>
>>>         A link to the draft JEP can be found here:
>>>         https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8303167&data=05%7C01%7CBruno.Borges%40microsoft.com%7C6890d9d207e745aed35208db2fe64b7f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638156438388716486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fi2CtWyIrc8df93dOp4FccEDari%2FnBzPGWMQ%2Byrlz3s%3D&reserved=0 <https://bugs.openjdk.org/browse/JDK-8303167>
>>>         
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8303167&data=05%7C01%7CBruno.Borges%40microsoft.com%7C6890d9d207e745aed35208db2fe64b7f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638156438388716486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fi2CtWyIrc8df93dOp4FccEDari%2FnBzPGWMQ%2Byrlz3s%3D&reserved=0 <https://bugs.openjdk.org/browse/JDK-8303167>>
>>>
>>>         In summary, the main motivation for this JEP is that there is
>>>         currently no implementation of JEP 436 (Virtual Threads)
>>>         
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F436&data=05%7C01%7CBruno.Borges%40microsoft.com%7C6890d9d207e745aed35208db2fe64b7f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638156438388716486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dJVsEWJee2e01yIfJiJTv9TOXNg2gYKslulot7dUWGE%3D&reserved=0 <https://openjdk.org/jeps/436>> for 32-bit platforms and without a vendor stepping forward to implement this it's unlikely that OpenJDK will be able to continue supporting 32-bit architectures. Another motivation is that Windows 10 (the last Windows operating system to support a 32-bit installation) will reach EOL on October 14, 20251.
>>>
>>>     When you build JDK 19+ to target windows-x86 then it will use an
>>>     alternative implementation of virtual thread that creates a kernel
>>>     thread for each virtual thread. So it doesn't scale but it's good
>>>     enough for Zero and ports that are a bit behind.
>>>
>>>     That said, it's a good topic to bring up. I don't expect dropping
>>>     windows-x86 will remove the burden of keeping the x86_32 port
>>>     working, to do that would require dropping linux-x86 too. So maybe
>>>     the discussion should be broadened to ask if the time is approaching
>>>     to remove the x86_32 port? At one point, one of the arguments to
>>>     keep linux-x86 working was reconditioning older computers but I
>>>     don't know if this is still the case. I see a mail to jdk-dev from
>>>     Mark Yagnatinsky that talks about JNI libs or drivers that are
>>>     32-bit only. There isn't much context but it would be surprising for
>>>     something that is actively maintained to not have a 64-bit build in
>>>     2023. He also mentions limiting resources but that may be a case
>>>     where an OS container should be used. It might be that you expand
>>>     the Motivation in draft JEP to cover these points.
>>>
>>>     -Alan
>>>
> 