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

[Peter Tribble]

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/