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

Wed Nov 6 11:40:09 UTC 2019

Hello!

Apologies for the late reply.

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.

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.

The community has set up a variety of machines in the GCC compile farm to make
this possible:

> https://gcc.gnu.org/wiki/CompileFarm

Any open source developer can request an account there and test their changes
on various different platforms.

And in Debian, every current OpenJDK releases is rebuilt on various architectures
regularly, the build logs are publicly available:

> https://buildd.debian.org/status/package.php?p=openjdk-11&suite=sid

Just replace the NN in openjdk-11 with any number from 8, 11, 12, 13
and 14. Matthias Klose is regularly updating the packages from upstream
minor releases and snapshots for the unreleased versions. Same happens
with GCC, where regularly snapshots are uploaded to unstable:

> https://buildd.debian.org/status/package.php?p=gcc-snapshot&suite=sid

Just click on the red or green fields to view the build log.

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

>> 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.

GCC is rather successful with their model, in my opinion, which can
be seen from the large number of supported targets which even includes
very obscure and old ones like PDP-11 and VAX.

There are currently some ports in danger of being removed for GCC-11:

> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

But at least for VAX and m68k people are working on saving them. I actually
started a Bountysource campaign to support the cc0 transition of the
m68k backend:

> https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

>> 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?

FWIW, LLVM currently has backends for quite some more architectures than
OpenJDK and usually the effort on the frontend side (I can only speak for
Rust here) is rather low. For example, adding support for s390x to Rust
contained only a few hundred lines of code:

> https://github.com/rust-lang/rust/commit/19b84088d76b8ded63cbaf12991213f4f437e689
> https://github.com/rust-lang/libc/commit/e7480eda34fd3e17f0dbcd183d918a235d9b97f9

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:

> https://github.com/llvm/llvm-project/tree/master/llvm/lib/Target

>> I think portability is important for a language to be widely
>> adopted. It's one of the reasons why C is so highly successful. It's
>> just available everywhere.
> 
> It is, and it's available everywhere because someone was prepared to
> invest the time and the money in it.

It depends, I would say. The BSD ports still won't work without external
patches, for example.

>> 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? I mean, I myself yanked out
old Itanium code last year or so that had been sitting in the code
for years after Itanium suport was dropped. No one was bothered by
it because it was guarded between #ifdefs.

PS: Sorry if my previous mail sounded a bit harsh. I just wanted to say
    that I'm trying my best to help with the portability efforts and
    I'm happy to provide access to machines with weird architectures
    if anyone is interested :).

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913