RFC: 32-bit x86 port maintenance, stepping down as maintainer

[Aleksey Shipilev]

Hi all,

TL;DR: I am stepping down as 32-bit x86 maintainer, this is a call for future maintainers, if any.

Longer version:

Due to historical reasons and my personal interest, I ended up being the formal maintainer for 
32-bit x86 [1]. The actual maintenance work seems to be be handled by a very small group of people. 
Unfortunately, the cost/benefit for maintaining 32-bit x86 is much more of the "cost" rather than 
"benefit" today.

Maintaining buildability for the port is somewhat simple, but maintaining parity with new features 
(Loom, FFM, Vector extensions, late GC barrier expansion, etc) is a major opportunity cost.

The benefits for having 32-bit x86 port are:

  a) Allow OpenJDK to run on 32-bit x86 platforms. AFAICS, the x86 world has firmly moved into 
64-bit realm. No new 32-bit-only x86 hardware is being manufactured. 32-bit x86 deployments are a 
rare sight, mostly in very old deployments. The industry support seems to dwindle down to match this 
reality. Windows 32-bit x86 support in OpenJDK had been already deprecated.

  b) Maintain and actively test at least some level of 32/64-bit cleanliness. This simplifies other 
32-bit ports maintenance, where simple things would be caught by 32-bit x86 port builds and tests 
first. Notable port that is covered this way is ARM32. Current GHA builds ARM32 Hotspot, so we still 
have some level of coverage there.

  c) Actively test the fallback paths for JVM/JDK features that are not implemented fully on some 
architectures. Loom's 1:1 scheduler, FFM Fallback Linker are the examples of this. Without 32-bit 
x86 that we can run more or less easily on current x86 hosts, there would be less coverage for these 
in tests like GHA.

  d) Provide backport safety into releases that are still shipping 32-bit x86 binaries. I have a gut 
feeling that deployments for old platforms like 32-bit x86 are realistically still stuck on JDK 8. 
Which also means, since we don't backport lots of intrusive stuff to JDK 8, the chance of production 
breakage would be small as well. Backporting to more modern releases like JDK 11, 17, 21 would come 
with some headache for those vendors who still build 32-bit x86 there.

I believe the sum of these benefits does not justify the maintenance cost, and that 32-bit x86 port 
has outlived its purpose.

Therefore, I am stepping down as 32-bit x86 maintainer.

Unless someone else steps in, this would leave the 32-bit x86 port effectively and formally 
unmaintained. We would still have 32-bit x86 Zero, which should still work like any other Zero 
implementation (slowly). Should no one take the reins for 32-bit x86 maintenance, I volunteer to do 
some cleanup tasks like disabling 32-bit x86 in GHA, amending build system with deprecation 
warnings, writing a formal deprecation JEP.

Being mindful this is probably a vacation season, I would like to set a somewhat longer 4 weeks 
deadline for anyone to step in. To be specific, the deadline is August 9, 2024, 23:59 UTC.

Thanks for reading, comments are welcome.

-- 
-Aleksey

[1] https://wiki.openjdk.org/display/HotSpot/Ports



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597