Proposed JEP - Deprecate the Windows x86-32 Port

[mark.yagnatinsky at barclays.com]

Re: OS container: I did specifically say “poor man’s” sandbox.  I have no idea how to properly set up an OS container for Java.  I doubt most Java developers do.
(Also, one more minor benefit of 32-bit: you get most of the benefit of Project Lilliput “for free”.)

From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Monday, February 27, 2023 2:16 PM
To: George Adams <George.Adams at microsoft.com>; jdk-dev at openjdk.java.net
Subject: Re: Proposed JEP - Deprecate the Windows x86-32 Port


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://clicktime.symantec.com/15siF9uGdxZ8YaSXTsiut?h=D4b5K7t_ryljdAePTgD7vO8uAnItk5odzqYUF578v_0=&u=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://clicktime.symantec.com/15siKz6Z6aEixXGT1S84W?h=z5b2188kOC1v5vTSu4tdsuYRq8Nnt__8qcx5hCJFwNY=&u=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

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230227/bc2238e2/attachment-0001.htm>