Supporting illumos (related to JEP-362) (original) (raw)
Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Oct 7 09:21:01 UTC 2019
- Previous message: Supporting illumos (related to JEP-362)
- Next message: Supporting illumos (related to JEP-362)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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!
- Previous message: Supporting illumos (related to JEP-362)
- Next message: Supporting illumos (related to JEP-362)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]