The future of 32-bit?

[Johan Vos]

Hi Thomas, all,

At the OCW workshop, I expressed my worries about removing all 32-bit code,
because I feared it would impact the ability to distribute Java apps to
mobile devices (via the existing stores). As someone pointed out, at the
very least 32-bit versions are not a requirement anymore. I did a bit of
research, and while there are still 32-bit devices in the field, the 2
major stores are pushing for 64-bits, and discouraging 32 bits -- something
we would call @Deprecated(forRemoval="true"). As a consequence, zero-32
code is no requirement for iOS, and arm-32 is no requirement for Android.

There are still usecases for the Pi Zero (v1) and older Raspberry Pi
devices (< 3). I have no idea about the installed base of those devices,
but I believe it is possible that this would be the largest group that will
suffer if 32-bit support was halted.

Having said that, I fully agree there is lots of additional work required
to keep 32-bit support (the (un)compressed classpointers are a good example
indeed). Though situation.

- Johan


On Fri, Apr 4, 2025 at 9:17 AM Thomas Stüfe <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. 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
> [2] 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20250404/e479f911/attachment-0001.htm>