The future of 32-bit?

[Thomas Stüfe]

Thanks for all the good points brought so far.

We will find plenty of reasons why it would be nice to have 32-bit. But
there are costs that need to be weighted against the benefits.

Pro:
- Java promises "write once runs anywhere". That promise has a lot more
punch when it, well, runs anywhere. That is an intangible benefit since
while it is real and benefits the ecosystem, its positive effects cannot be
measured.
- 32-bit can be used, arguably, to get JVMs with a very low footprint. But
with CompressedOops and CompactObjectHeaders that argument loses its bite
somewhat.

Con:
- Development costs: A large part of the 32-bit effort is spent on making
new developments 32-bit-ready. Things like Loom, Lilliput etc. This effort
is mostly shouldered by those developers who are conscious enough not to
break 32-bit when developing something new. Or those who stepped up and
fixed arm32 or x86 after they had been broken for a while.
- Opportunity costs: keeping 32-bit drags down development velocity.
Development time is a finite resource. That time could be spent elsewhere:
fixing bugs, improving the JVM. 32-bit also increases technical debt,
therefore ongoing maintenance costs. The worsening build support
exaggerates this problem.
- Build and testing effort: testing pipelines must be maintained and issues
triaged and fixed.

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.

Cheers, Thomas


On Fri, Apr 4, 2025 at 12:41 PM Glavo <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>
> 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/93fb837b/attachment.htm>