Supporting illumos (related to JEP-362)
peter.firmstone at zeus.net.au
Wed Oct 9 04:15:03 UTC 2019
+1 for gcc.
On 7/10/2019 7:21 PM, Magnus Ihse Bursie wrote:
> 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
>> 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.
>> 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
>> driving this within illumos, and am happy to engage with others to
>> a successful outcome.
>> Thank you!
More information about the jdk-dev