AW: The future of 32-bit?

[Thomas Stüfe]

On Tue, Apr 8, 2025 at 4:46 PM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2025-04-04 12:25, Doerr, Martin wrote:
>
> 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.
>
> This ^^^.
>
> The question is not *if* we should stop supporting 32-bit, but *when*. I
> don't see anyone arguing that 32-bit platforms have a long-term future. We
> can keep the 32-bit JDKs on life support, for a longer or a shorter time,
> but frankly, that is what it is.
>
> Dropping 32-bit completely somewhere between now and the next LTS release
> might perhaps be a good idea.
>
> As with any other platforms in the JDK, the remaining 32-bit support
> (arm-32 and zero) should have a sponsor, someone (organization or company)
> backing it up. That is the general requirement we have for adding a new
> platform, and we should have the same requirement for keeping old platforms
> in. If we have such a sponsor, then the onus is on them to keep the
> platform up to date with continuous development of the JDK. And if no-one
> is willing to step up and assume such a role, well, that is a clear
> indication that while it might be "nice to have" 32-bit support, no-one is
> willing to pay the price for it. And if so, it should go.
>
>
I 100% agree with this. Let's remove 32-bit support after JDK 25. For the
record, this should also include removing zero 32-bit.

/Thomas
>
> /Magnus
>
>
>
>
> Best regards,
>
> Martin
>
>
>
> *Von: *jdk-dev <jdk-dev-retn at openjdk.org> <jdk-dev-retn at openjdk.org> im
> Auftrag von Johan Vos <johan.vos at gluonhq.com> <johan.vos at gluonhq.com>
> *Datum: *Freitag, 4. April 2025 um 11:17
> *An: *Thomas Stüfe <thomas.stuefe at gmail.com> <thomas.stuefe at gmail.com>
> *Cc: *JDK Dev list <jdk-dev at openjdk.org> <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>
> 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/20250424/91e2076c/attachment-0001.htm>