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

[coleen.phillimore at oracle.com]

Hi, I wanted to add to what Andrew Haley wrote about the cost of 
maintaining the 32 bit x86 port.  A long time ago, we consolidated the 
template interpreter code so that there was only one source file to 
change when working on that code.  This required that we only use the 4 
registers that the 32 bit port provided, with some conditionals for 
knowing r15 is the thread register for 64 bits. With new work coming in 
for Valhalla, restricting our use to only 4 registers is really 
difficult and results in poor code.  Internally, we've been talking 
about splitting out and moving all the 32 bit code to a new directory, 
which will result in almost immediate bit rot.

It would be nicer to deprecate this code in favor of using the Zero 
based interpreter for the linux-x86 port.  We started on a JEP for that, 
even though it's awkward since we don't support this port at Oracle, but 
we want to move the code out of the way.

Thanks,
Coleen

On 7/10/24 10:09 AM, Andrew Haley wrote:
> On 7/10/24 12:06, Aleksey Shipilev wrote:
>
> > 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.
>
> One other thing that is important: 32-bit support is already broken in
> some ways, and especially the x86 ABI Linux is not compliant in that
> it calls native code with a misaligned stack pointer. This is
> surprisingly hard to fix.
>
> Having to keep everything working on 32-bit x86 is a drain on
> everyone. The back end contains 527 separate instances of #ifdef
> _LP64, and every one of these is a burden for maintainers. (I just had
> to add a few more.) It would be better for everyone to remove the
> 32-bit port, rather than have it half-maintained.
>
> IMHO, rather than keep 32-bit x86 going, it would make more sense to
> concentrate on trying to get the older 32-bit OpenJDK backport
> versions in good shape. I don't think that it's possible to do both
> without a lot of effort.
>