AW: The future of 32-bit?

[Doerr, Martin]

Hi all,

even if we deprecate 32 bit now, arm32 will still be usable with JDK 25 LTS for quite some time.

The big question is if there will still be a significant demand in 2 years.
I also wonder when other projects will terminate arm32 support.

Best regards,
Martin

Von: jdk-dev <jdk-dev-retn at openjdk.org> im Auftrag von Johan Vos <johan.vos at gluonhq.com>
Datum: Freitag, 4. April 2025 um 11:17
An: Thomas Stüfe <thomas.stuefe at gmail.com>
Cc: JDK Dev list <jdk-dev at openjdk.org>
Betreff: Re: The future of 32-bit?
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<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. 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/404419c2/attachment-0001.htm>