<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 27, 2023 at 8:15 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<br>
<div>On 27/02/2023 11:04, George Adams
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
Hi all,</p>
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
</p>
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
I’ve been asked to socialize my proposed JEP to
deprecate the Windows x86-32 port on this mailing list.</p>
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
</p>
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
A link to the draft JEP can be found here:<span> </span><a href="https://bugs.openjdk.org/browse/JDK-8303167" style="color:rgb(0,120,212);text-decoration:underline" target="_blank">https://bugs.openjdk.org/browse/JDK-8303167</a></p>
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
</p>
<p class="MsoNormal" style="color:rgb(33,33,33);margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:1.5">
In summary, the main motivation for this JEP is that
there is currently no implementation of <a href="https://openjdk.org/jeps/436" title="Follow link" style="color:rgb(0,120,212);text-decoration:underline" target="_blank">JEP
436 (Virtual Threads)</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<span> </span><span dir="ltr" style="color:currentcolor;text-decoration:underline rgb(0,120,212);font-size:inherit"><span dir="ltr" style="text-decoration-color:rgb(0,120,212)">on
October 14</span></span>, 20251.</p>
<br>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
-Alan<br>
<br></div></blockquote><div><br></div><div>I would be unhappy if x86 were to go. There is a place for 32-bit JVMs for small java apps. A 32-bit JVM can have a considerably lower footprint than its 64-bit pendant if the app is dominated by native memory. I recently measured the footprint for 32-bit vs 64-bit JVMS on a 64-bit Linux host and in some cases there was > 70% overhead. I can dig up the results if there is interest.<br><br>Also, we want to keep arm, right? The arm port is important for a lot of SBCs out there. Keeping x86 means more testing for 32-bit. I don't think many people test on arm.<br></div><div> </div></div></div>