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

[Mikael Vidstedt]

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

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?

Cheers,
Mikael