The future of 32-bit?

[Dalibor Topic]

On 04/04/2025 16:12, Thomas Stüfe wrote:
> I am not arguing for or against 32-bit. But I think we should either 
> stay on the boat or go ashore. Arm32 as the only realistic test option 
> is not a good solution.

Fwiw, ARM announced a move to 64 bit only cores almost two years ago. [0]

Without exciting new 32 bit "anywheres" to run on coming up in the 
future, the needs of existing 32 bit applications are probably already 
well served by (updates to) the JDK versions they are deployed with, 
rather then by offering new language and runtime capabilities in older 
environments for which a decreasing amount of new Java code is going to 
be written for.
cheers,
dalibor topic

[0] https://newsroom.arm.com/blog/64-bit

> 
> Cheers, Thomas
> 
> 
> On Fri, Apr 4, 2025 at 12:41 PM Glavo <zjx001202 at gmail.com 
> <mailto:zjx001202 at gmail.com>> wrote:
> 
>     Hi,
> 
>     I think 32-bit is not abandoned by everyone.
>     As far as I know, new architectures like RISC-V and LoongArch still
>     have 32-bit variants and do have users using them.
> 
>     Although these 32-bit variants are often used in resource-
>     constrained scenarios such as embedded systems,
>     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.
> 
>     Glavo
> 
>     On Fri, Apr 4, 2025 at 3:16 PM Thomas Stüfe <thomas.stuefe at gmail.com
>     <mailto:thomas.stuefe at gmail.com>> wrote:
> 
>         Hi,
> 
>         Continuing our discussion at the last FOSDEM workshop, I would
>         like to know what we think about the future of 32-bit support.
> 
>         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.
> 
>         We have two remaining 32-bit platforms, at least in theory:
> 
>         - arm32
>         - zero 32-bit
> 
>         Zero 32-bit has been broken for a long while now; see https://
>         bugs.openjdk.org/browse/JDK-8353699 <https://bugs.openjdk.org/
>         browse/JDK-8353699>. I try this occasionally and don't remember
>         the last time it built successfully.
> 
>         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.
> 
>         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.
> 
>         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.
> 
>         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.
> 
>         But I expect this periodic brokenness to worsen now after the
>         removal of x86. This is not a good situation.
> 
>         Thank you, Thomas
> 
>         [1] https://bugs.openjdk.org/browse/JDK-8353699 <https://
>         bugs.openjdk.org/browse/JDK-8353699>
>         [2] https://bugs.openjdk.org/browse/JDK-8350754 <https://
>         bugs.openjdk.org/browse/JDK-8350754>
>         [3] https://bugs.openjdk.org/browse/JDK-8350754?
>         focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 <https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275>
> 

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann