<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>I think 32-bit is not abandoned by everyone.</div><div>As far as I know, new architectures like RISC-V and LoongArch still have 32-bit variants and do have users using them.</div><div><br></div><div>Although these 32-bit variants are often used in resource-constrained scenarios such as embedded systems, </div><div>and their users may not be very interested in Java, I still don't want to see OpenJDK completely abandon the possibility of supporting them.</div><div><br></div><div>Glavo</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 4, 2025 at 3:16 PM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.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 dir="ltr"><div>Hi,</div><div><br></div><div>Continuing our discussion at the last FOSDEM workshop, I would like to know what we think about the future of 32-bit support.</div><div><br></div><div>Supporting 32-bit became a lot more cumbersome after the x86 port was removed. Before, one could easily build 32-bit on the ubiquitous x64 platforms with --target-bits=32; that is not an option anymore.</div><br>We have two remaining 32-bit platforms, at least in theory:<br><br>- arm32<br>- zero 32-bit<br><br>Zero 32-bit has been broken for a long while now; see <a href="https://bugs.openjdk.org/browse/JDK-8353699" target="_blank">https://bugs.openjdk.org/browse/JDK-8353699</a>. I try this occasionally and don't remember the last time it built successfully.<br><br>Arm32 is the last bastion of serious 32-bit support, and the last option for testing 32-bit coding. So, one needs to build arm32 (best done via crossbuild), then spin up an arm32 system to test the changes. I do this with a slow-as-molasses Raspberry. It is not fun.<br><br>Unfortunately, maintaining 32-bit is not as easy as "make sure it builds and fix smaller things". It requires real development, especially in the context of ongoing object header work.<br><br>32-bit also means we need to keep some form of uncompressed class pointers around, which makes the eventual removal of uncompressed class pointers (see [2]) more difficult. The current plan is to implement some sort of fake-compressed-class-pointer mode [3], which sounds easy in theory but is still tricky work I'd rather avoid.<br><br>Keeping up 32-bit development in the face of dwindling options to build and test is a struggle. It has been a struggle for some time now. Even the comparatively well-maintained arm32 platform had periodic weeks of brokenness after heavy upstream changes. And this is not intended to diminish the effort put in by the arm32-maintainers. They are few, and they do good work. <br><br><div>But I expect this periodic brokenness to worsen now after the removal of x86. This is not a good situation.</div><div><br></div><div>Thank you, Thomas</div><div><br></div>[1] <a href="https://bugs.openjdk.org/browse/JDK-8353699" target="_blank">https://bugs.openjdk.org/browse/JDK-8353699</a><br>[2] <a href="https://bugs.openjdk.org/browse/JDK-8350754" target="_blank">https://bugs.openjdk.org/browse/JDK-8350754</a><br>[3] <a href="https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275" target="_blank">https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275</a><br><br></div>
</blockquote></div>