New candidate JEP: 362: Deprecate the Solaris and SPARC Ports

[Andrew Haley]

On 11/6/19 11:40 AM, John Paul Adrian Glaubitz wrote:
> 
> On 11/4/19 12:34 PM, Andrew Haley wrote:
>>> I feel like that OpenJDK is starting to develop into a direction of
>>> low portability again. When I started working on OpenJDK, I had
>>> hoped to be able to help make OpenJDK and Java more portable. But I
>>> feel there is no real interest in the OpenJDK community to make Java
>>> available on a wide variety of platforms besides x86, ARM, POWER and
>>> S390x.
>>
>> Right. It's not about whether people are interested in the port but
>> whether they are prepared to invest in it. From the AArch64 port point
>> of view, I know just how much investment that is.
> 
> I already mentioned this in a private reply to someone else: I think
> one of the problems with OpenJDK in this regard is that the core developers
> are testing their changes on the platforms supported by Oracle only.

That's true if and only if you believe that all of the "core"
developers work for Oracle. I don't believe that, and it's not been
true for some time.

> I very often see mails with the subject "RFR-NNNNNN: Build broken on
> $ARCH after JDK-XXXXXXX" which is something I don't see that often
> in other projects like Rust or GCC. Sure, they also have regressions
> that affect certain architectures only, but in OpenJDK this happens
> much more frequently from what I have observed.
>
> The procedure seems to be that someone from the core team makes a
> change that affects architecture-specific code, but since Oracle
> themselves officially support ARM64 and x86_64 only, the changes are
> not done or tested on the remaining architectures, so after that,
> the maintainers for the ARM32, POWER and s390X ports have to send
> patches to fix the breakage.
>
> In my opinion, it would be more efficient if everyone tested their
> changes on all supported architectures. This way potential
> regressions are detected much earlier and will most likely not reach
> get committed to the main repository.

Sure, and there's been some work going on for a while to automatically
test things.

> Additionally, lots of folk from the Gentoo, Debian and *BSD communities
> are usually very happy to help with specific ports.

Yes, and organizations like Adopt are doing the same, as are us and
SAP, etc., etc.

>>> I understand that there are commercial interests and that
>>> maintaining portable code requires time and effort. But I also see
>>> that other compiler projects like Rust and GCC achieve high
>>> portability without requiring a very high maintenance effort.
>>
>> As someone who is still occasionally a GCC maintainer, I'm not sure if
>> I believe that. There is a high maintenance effort in keeping GCC
>> targets going, and if any port becomes unsupported it is dropped.
> 
> That's not the experience I made. Usually GCC developers make their
> changes across all architectures and test them. It's not that code
> for m68k is touched by the m68k maintainer only, for example.

Well, maybe. It's nice where possible, but it's not always
possible. Given an automated test farm that does the right things it's
to some extent possible, but I don't relish trying to work on a
HotSpot bug on a machine I don't have. And yes, I know loan machines
are available, and I've used them.

>>> I wish Shark wouldn't have fallen into oblivion [2] as using LLVM is
>>> a really good idea in order to achieve both portability and
>>> reasonable performance which is why LLVM is popular with other
>>> languages like Rust, Swift, Julia and many more [3].
>>
>> Shark was a good idea (it was -- partly -- my idea) but it couldn't
>> keep up. It might not be a bad idea to create a "modern" Shark,
>> perhaps along the lines of Azul's Falcon.
> 
> What was the main reason it couldn't keep up? Lack of interest or was
> it that OpenJDK changed too much low-level code too often?

LLVM, especially its JIT support, was horribly unstable. The only way
to get a bug fixed was to "wait for the next release", at which point
something else would break, repeat ad nauseam. We'd have had to fork
LLVM and tried to stabilize the silly thing.  Also, the support for
garbage collection was awful. I believe this is fixed now.

Later on they rewrote the JIT support and I hear it's much better. In
hindsight LLVM just wasn't ready, and was oversold.

> If OpenJDK still had Shark, we would get native support for MIPS, SPARC
> and even RISC-V almost for free as LLVM supports these targets:

No, because of all the runtime code. It's not just about the compiler.
Would you like to lead a project to do it? I'd love that and would
happily support you.

>>> Would it be possible to just keep the SPARC port for Linux?
>>
>> If someone wants to support it, sure. But most of the big-ticket jobs
>> Mikael Vidstedt listed to do aren't related to the host OS.
> 
> Understood.
> 
>> It is extremely important that we have no dead and rotting code in
>> OpenJDK.  Of course we love to encourage as many ports as possible,
>> but they have to build and run and pass the tests, because if they
>> don't that hurts Free Software.
> 
> Is bit rot really that much of a problem?

Yes. It's the reason that unmaintained ports get yanked out of GCC
pretty quickly.

[Sorry, I know I didn't reply to every point you made, and had to
delete some things.]

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671