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

[George Adams]

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>
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>> 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://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%7CGeorge.Adams%40microsoft.com%7C645a895d36614b8ebfa408db1a4db724%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638132693333901376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DdaeznIQYUT4W4SQ4tlMDVUs3pQupv5mG2LrUYXN6J0%3D&reserved=0>

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%7CGeorge.Adams%40microsoft.com%7C645a895d36614b8ebfa408db1a4db724%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638132693333901376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QD41i%2B7kj3j01c5%2B3b0pRSx6NKY751CUnfrele7Har0%3D&reserved=0> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230303/c568b074/attachment-0001.htm>