Supporting illumos (related to JEP-362)

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Oct 7 09:21:01 UTC 2019


On 2019-10-04 16:02, Peter Tribble wrote:
> The illumos project is a continuation of the OpenSolaris project. It
> has an active community, has a number of distributions, and a number
> of commercial companies use it as the basis for their products.
>
> Currently, illumos uses the Solaris port of OpenJDK, which mostly
> works because Solaris and illumos share a common heritage.
>
> The recent JEP 362 (https://openjdk.java.net/jeps/362) impacts
> illumos, as OpenJDK currently classes us as a Solaris port.
>
> Prompted by JEP 362, we would like to see the creation of an illumos
> porting project, distinct from the Solaris port. There's still work to
> be done on defining that project and establishing its context - more
> below.
>
> One difference is that illumos ports tend to use gcc, rather than the
> Studio compilers. This should make illumos much closer to the Linux
> and BSD ports.
 From a pure build point of view, Solaris Studio has been one of the 
major problems with the Solaris port. It has non-standard behavior, 
lacking lots of essential functionality, and has continuously included 
new compiler bugs in every release. Changing to gcc will certainly help 
in that regard. But you must realize that a switch will not be trivial 
-- there are numerous instances where the assumption "solaris means 
solstudio" is made, often without the original author realizing this. 
While the intention in the build system has always been that the idea of 
"toolchain" and of "operating system" should be separate, in practice we 
have a 1-to-1 relationship between toolchains and OSes, and that makes 
it hard in practice to uphold this distinction, since it becomes purely 
theoretical.

If it will turn out that the community will step up to both support an 
ongoing Solaris port (using solstudio), and also add a new Illumos port 
(using gcc), the already-underdeveloped Solaris code will need to be 
re-written flexible enough to accommodate two different compilers. The 
only platform so far where we do this is on Linux where both gcc and 
clang are supported (but in practice, only gcc is used), and they are 
way more closely related than gcc and solstudio. This might turn out to 
be a hard task, where the responsibility needs to be shared between an 
ongoing solaris port and a new Illumos port.

Of course, this only covers the build part. The *real* hurdle will of 
course lie in keeping the actual code base up to date with the changes 
going on in the rest of the JDK.

/Magnus


>
> Separating illumos from Solaris also has a precedent in the Go project,
> where the recent Go 1.13 release recognized illumos as a separate (but
> related) platform.
>
> If others wish to see Solaris support within OpenJDK continue, we're
> happy to work with that. It still makes sense to regard Solaris and
> illumos as different platforms, as both the platform and toolchain
> have diverged from their shared ancestry.
>
> One possibility I can see would be for the community to support the
> GCC toolchain for the Solaris port rather than Studio. That would be
> very similar to an illumos port.
>
> Likewise, illumos still supports the SPARC architecture. If SPARC
> support was retained for other operating systems, we would be happy to
> collaborate on that. Supporting SPARC is not something we could do on
> our own, though, and it wouldn't be a primary focus for us.
>
> At this point we're interested in what other proposals there might be
> to respond to JEP 362, so that we can ensure that the illumos proposal
> does not unnecessarily overlap or conflict with other work. I'm currently
> driving this within illumos, and am happy to engage with others to ensure
> a successful outcome.
>
> Thank you!
>



More information about the jdk-dev mailing list