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

Tue Nov 5 08:13:25 UTC 2019

Hi,

I would like to highlight SAPs interest in the solaris/sparc
ports, as well as share my experience with maintaining
ports.

We are supporting a lot of Java code on solaris-sparc and 
solaris-x86_64. 
Currently, this code is running on Java 5-8.  Since Java 9, 
it is considered to move much of this to higher Java, 
and it might finally happen now. The move from Java 11 to 
Java 17, the next LTE, should be much more easy, and
thus I, personally, assume it might happen faster, i.e. 
while Solaris is still supported.
Therefore looking long term, I would assume that a 
Solaris port in 17 will be precondition to run SAP code on
these platforms. But we will really only know whether we
need this after the next LTE is out a while, i.e., 2022 or later.
On the other side, SAP does not really feel like supporting
a platform that is basically owned by Oracle. 

With respect to the upcoming projects and the effort to 
maintain a port:
We are maintaining the ppc, s390 and aix ports. We are
investing a lot in correctness, less in supporting all the new
features as the GCs, intrinsics, CDS etc. The effort is 
definitely more than a spare-time project, but acceptable.
It is bigger if there are mandatory larger changes, as the 
GC-interfaces, var-handles, thread-local-handshakes.
The effort of these, given our existing build- and test 
infrastructure, was a few weeks each.  (A huge one was
the first implementation of method-handles ;), another
huge one would be the graal port.)

Wrt. to the upcoming projects, I don’t know about the
effort they are causing, nor about their timeline.
But I know that this is a continuous argument on the
Oracle side not to do this-or-that. In several of our 
RFEs it was argued that the change should not be
made because of this or that project, and now, 
up to 3 Java versions later, the projects are still not 
targeted for Java 14.

Therefore I guess that these larger efforts must only be
invested at a later point in time, so that supporting
solaris/sparc until then is possible with medium effort,
and dropping it when an expensive change must be 
made can be reconsidered.  Maybe, at that point in time,
someone else steps up, or helps out with the porting.
(It might be SAP. If we know we need solaris/sparc, and
we did the port of a feature for ppc/s390/aix, implementing
a once-in-a-time effort for solaris/sparc might be feasible.)

Best regards,
  Goetz

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Peter Tribble
> Sent: Montag, 4. November 2019 13:11
> To: Mikael Vidstedt <mikael.vidstedt at oracle.com>
> Cc: jdk-dev at openjdk.java.net; glaubitz at physik.fu-berlin.de
> Subject: Re: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports
> 
> On Wed, Oct 30, 2019 at 10:41 PM Mikael Vidstedt
> <mikael.vidstedt at oracle.com>
> wrote:
> 
> >
> > > On Sep 27, 2019, at 7:58 AM, mark.reinhold at oracle.com wrote:
> > >
> > > https://openjdk.java.net/jeps/362
> >
> > John/Peter,
> >
> > Thanks for your interest in the SPARC and Solaris ports.  If you really
> > want to sign up to maintain these, I’d like first to help you understand
> > the work that’d be involved.
> >
> 
> Thanks for the summary.
> 
> To be clear, I'm not suggesting that I want to support all of this. It's
> perhaps unfortunate
> that JEP-362 is actually 3 distinct (if related) deprecations:
>  1. Solaris the platform
>  2. SPARC the CPU architecture
>  3. Studio the toolchain
> 
> From the point of view of the illumos project, as an OpenSolaris derivative
> (both Solaris and illumos
> identify as SunOS), we're interested in just the first of those.
> 
> As a project, while illumos does have a certain element of support for
> SPARC (that certain element
> being a couple of us in our spare time), we have neither the resources not
> the requirement to support
> newer JDK versions on SPARC, so SPARC would be out of scope.
> 
> As far as the toolchain is concerned, we are essentially pure gcc, and
> neither have, nor are interested
> in, support for Studio. In fact, the current support for Studio is getting
> in our way, as we have to patch
> Studio out and replace it with gcc. (And yes, that work has been done.)
> 
> Several major projects and features are slated to make their way into the
> > mainline JDK in the near future.  Many of them require significant changes
> > in the JVM and in platform/architecture specific code, and you’d be
> > responsible for them.  A few of the most significant ones:
> >
> > * Valhalla/inline types
> >
> > In project Valhalla we’re making significant changes to the core parts of
> > the JVM. Among other things there’s a whole new calling convention for
> > inline types, which requires changes to the JIT compiler(s), the various
> > adapters, etc.
> >
> > * Loom
> >
> > The continuation yielding/thawing mechanism is *heavily* dependent on
> > platform specific code weaving for performance, as is the stack frame
> > manipulation code.
> >
> > * Panama
> >
> > The foreign function logic has an ABI specific component to it, which
> > would need to be ported to Solaris and/or SPARC.
> >
> > * Adopting a newer version of the C++ standard
> >
> > We’re looking at adopting a newer version of the C++ standard (C++14 or
> > C++17) along with the features that come with it.  Oracle Studio does not
> > support the full C++14 standard, and AFAIK does not support C++17 at all.
> >
> >
> > The above isn’t meant to be an exhaustive list, but will hopefully give
> > you a rough idea of what you’d need to do in order to maintain these
> > ports.  A lot of the work is either required for specification compliance,
> > or is central to the performance model of Java. Also, keep in mind that a
> > lot of the functionality would need to be implemented in three different
> > JIT compilers: C1, C2, and Graal.
> >
> > In addition to the feature work and code changes it’s worth stressing that
> > continuous testing of the ports is needed to ensure high quality. The
> > machine resources and human time required to analyze and address failures
> > are significant, and shouldn’t be underestimated.
> >
> > So, given this information, are you still interested?
> >
> 
> The illumos community is interested in there being an illumos port, on x64,
> using the gcc
> toolchain. Exactly how that's delivered is open; my initial thought was
> that we would do this
> as an illumos/gcc porting project under the auspices of the Porters Group.
> 
> Thanks,
> 
> --
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/