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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
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/

More information about the jdk-dev mailing list