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

[Aleksey Shipilev]

Hi David,

On 10.07.24 03:02, David Alayachew wrote:
> I posted this in reddit too, but I want to see what's required of someone to do this because I am 
> genuinely considering stepping up too.

Noted.

There are different facets of porting work. Off the top of my head, in order of growing complexity:

1. Running builds and fixing build failures. This is currently simplified by having GHA build the 
full Linux 32-bit builds. When the support for the port dwindles, I expect 32-bit builds to be 
retracted to just building Hotspot, not the full JDK. So maintainers would be exposed to more 
surprising failures. Speaking from before-GHA experience, I would say it takes a few hours a week to 
track and fix these.

2. Running tests and fixing test failures. This is currently simplified by having GHA run at least 
some basic tests. Quite some test failures are just tests misconfigured for 32-bit builds, like 
requesting too large heap size, asking for features that are not available, using flags that are not 
applicable to 32-bit VMs. From experience, this takes a few hours a week to maintain healthy test 
runs, assuming they expose no product bugs.

3. Fixing bugs. Most of the headache there are compiler/runtime parts that have arch-specific code. 
32-bit x86 is a bit peculiar here, because it covers quite large spectrum of possible hardware 
configs. Back in the days when I was running the tests, the test configs covered UseSSE={0,1,2,3,4}, 
UseAVX={0,1,2,3}. x87 bugs (-XX:UseSSE=0) are the most fun. You may choose not to care, but it would 
also be odd to pass tests on EPYC servers with UseAVX=2, and then fail on the actual hardware in the 
field that does not even know what AVX is. Depending on the complexity, this can take anywhere from 
1 day a week to full week of tinkering with things. There are some bugs that might take much longer 
to fully understand.

4. Porting features. This a major hurdle, which often requires in-depth knowledge of VM internals, 
and significant perseverance for working through the issues. Simple things (e.g. removing IC stubs) 
take a couple of hours. Complicated things (e.g. Loom ports, G1 barrier expansion) would take weeks 
to iron out the wrinkles. A saner path might be working out how to disable particular features on 
32-bit x86 cleanly. Working on 32-bit x86 is both simpler than other arches, since there is usually 
an inspirational 64-bit x86 code to borrow from, and also more complicated than other arches, 
because it has peculiarities like not having a separate thread register, which causes massive 
headaches when porting low-level code.

I would say properly maintaining the port at 1..3 level can take about 1 full-time engineer with 
prior Hotspot/JDK experience, less when you know where to cut the corners. So I would not recommend 
this as a starter project. For a reasonable probability of success, you need to have experience with 
Hotspot/JDK development, or have enough time to work it out as you go, or both.

HTHS,
-Aleksey



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