<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-CA" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hey Alex,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks for the feedback!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I went ahead and proposed changes based on your comments for George to review/merge:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a href="https://github.com/microsoft/openjdk-proposals/pull/11">https://github.com/microsoft/openjdk-proposals/pull/11</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Alex Buckley <alex.buckley@oracle.com><br>
<b>Date: </b>Tuesday, March 28, 2023 at 4:43 PM<br>
<b>To: </b>jdk-dev@openjdk.org <jdk-dev@openjdk.org>, George Adams <George.Adams@microsoft.com>, Bruno Borges <Bruno.Borges@microsoft.com><br>
<b>Subject: </b>Re: [EXTERNAL] Re: Proposed JEP - Deprecate the Windows x86-32 Port<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">One last try to reach George Adams with comments on his JEP.<br>
<br>
The mail below is also linked in a comment from the JEP (JDK-8303167).<br>
<br>
Alex<br>
<br>
On 3/3/2023 9:53 AM, Alex Buckley wrote:<br>
> Hi George,<br>
> <br>
> A couple of stylistic points on the JEP:<br>
> <br>
> 1. Goals and Non-Goals usually appear before Motivation, e.g., as done <br>
> in JEP 362.<br>
> <br>
> 2. In Alternatives, there is a paragraph about "It is also known that <br>
> 32-bit JVMs on Windows ...". This paragraph describes what a user could <br>
> do if this JEP proceeds, but Alternatives is usually about what the JEP <br>
> author could do instead the thing they just spelled out in the Description.<br>
> <br>
> I recommend moving the paragraph to Risks & Assumptions, where you <br>
> already have a user story about WOW64. You could say something like the <br>
> text below. I made numerous edits for tone (I thought "in the wild" was <br>
> a bit flippant) and for clarity (there was an "older" and "newer" theme <br>
> going on that I thought unnecessary) and most importantly to spell out <br>
> the assumption.<br>
> <br>
> -----<br>
> It is known that 32-bit JVMs on Windows are still used due to <br>
> integration with 32-bit DLLs. These users cannot migrate directly to <br>
> 64-bit JVMs, because a 64-bit process on Windows cannot load a 32-bit <br>
> DLL. This JEP assumes that these users can continue to run a 32-bit JVM <br>
> to integrate with these native libraries, and expose their functionality <br>
> over some form of remote API that can be consumed by code in a 64-bit <br>
> JVM, within the same environment.<br>
> -----<br>
> <br>
> Alex<br>
> <br>
> On 3/3/2023 2:43 AM, George Adams wrote:<br>
>> Thank you so much for the feedback that everyone has provided so far. <br>
>> I have pushed a handful of changes to the JEP draft to help clarify <br>
>> some points. Most notably, this JEP does not intend to deprecate any <br>
>> other x86_32 ports.<br>
>><br>
>> Thanks<br>
>><br>
>> George Adams<br>
>><br>
>> *From: *Glavo <zjx001202@gmail.com><br>
>> *Date: *Wednesday, 1 March 2023 at 12:08<br>
>> *To: *Alan Bateman <Alan.Bateman@oracle.com><br>
>> *Cc: *George Adams <George.Adams@microsoft.com>, <br>
>> jdk-dev@openjdk.java.net <jdk-dev@openjdk.java.net><br>
>> *Subject: *[EXTERNAL] Re: Proposed JEP - Deprecate the Windows x86-32 <br>
>> Port<br>
>><br>
>><br>
>><br>
>> You don't often get email from zjx001202@gmail.com. Learn why this is <br>
>> important <<a href="https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/LearnAboutSenderIdentification</a>><br>
>><br>
>><br>
>><br>
>> I have seen many Intel Celeron N/J machines with memory <4GiB. <br>
>> Although x86-32 is old, its non-heap memory footprint is lower, so it <br>
>> works better under resource constraints.<br>
>><br>
>> And although Windows 11 does not provide 32-bit images, as far as I <br>
>> know, Microsoft does not plan to give up support for running 32-bit <br>
>> programs on 64-bit systems.<br>
>><br>
>> 32-bit programs are still an important part of Windows, a large number <br>
>> of programs are still 32-bit.<br>
>><br>
>> For a considerable number of client applications, upgrading to 64-bit <br>
>> has only negative benefits.<br>
>><br>
>> They only need a little memory and are not sensitive to performance.<br>
>><br>
>> What will 64-bit bring to them? Higher resource consumption and poor <br>
>> compatibility (cannot run on x86-32 or Windows 10 on Arm systems)<br>
>><br>
>> I know that maintaining a port requires a lot of manpower, so I can't <br>
>> ask you to do anything. But I really hope it will continue to be <br>
>> maintained.<br>
>><br>
>> On Tue, Feb 28, 2023 at 3:15 AM Alan Bateman <Alan.Bateman@oracle.com <br>
>> <<a href="mailto:Alan.Bateman@oracle.com">mailto:Alan.Bateman@oracle.com</a>>> wrote:<br>
>><br>
>> On 27/02/2023 11:04, George Adams wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> I’ve been asked to socialize my proposed JEP to deprecate the<br>
>> Windows x86-32 port on this mailing list.<br>
>><br>
>> A link to the draft JEP can be found here:<br>
>> <a href="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</a><br>
>> <br>
>> <<a href="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</a>><br>
>><br>
>> In summary, the main motivation for this JEP is that there is<br>
>> currently no implementation of JEP 436 (Virtual Threads)<br>
>> <br>
>> <<a href="https://openjdk.org/jeps/436">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</a>> 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.<br>
>><br>
>> When you build JDK 19+ to target windows-x86 then it will use an<br>
>> alternative implementation of virtual thread that creates a kernel<br>
>> thread for each virtual thread. So it doesn't scale but it's good<br>
>> enough for Zero and ports that are a bit behind.<br>
>><br>
>> That said, it's a good topic to bring up. I don't expect dropping<br>
>> windows-x86 will remove the burden of keeping the x86_32 port<br>
>> working, to do that would require dropping linux-x86 too. So maybe<br>
>> the discussion should be broadened to ask if the time is approaching<br>
>> to remove the x86_32 port? At one point, one of the arguments to<br>
>> keep linux-x86 working was reconditioning older computers but I<br>
>> don't know if this is still the case. I see a mail to jdk-dev from<br>
>> Mark Yagnatinsky that talks about JNI libs or drivers that are<br>
>> 32-bit only. There isn't much context but it would be surprising for<br>
>> something that is actively maintained to not have a 64-bit build in<br>
>> 2023. He also mentions limiting resources but that may be a case<br>
>> where an OS container should be used. It might be that you expand<br>
>> the Motivation in draft JEP to cover these points.<br>
>><br>
>> -Alan<br>
>><o:p></o:p></span></p>
</div>
</div>
</body>
</html>