New candidate JEP: 362: Deprecate the Solaris and SPARC Ports (original) (raw)

Peter Tribble peter.tribble at gmail.com
Mon Nov 4 12:11:04 UTC 2019

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/

More information about the jdk-dev mailing list