But wait, what does this changeset actually mean? Sun Studio on Linux?
Does that make sense? YES! It does and it's true.
Mind you, it's just Hotspot that can be built with the Sun Studio
compilers on Linux right now, but it's an important piece, the Hotspot
C++ code is not a trivial pile of code to compile and optimize
correctly. My hat is off to the Sun Studio team in making this all
happen.
What should be interesting now is how well the rest of the tools
work like dbx and the analyzer/collector.

Wednesday Apr 30, 2008

We are starting work to update the compilers and build OS releases
used to build OpenJDK7 and JDK7.
The implications of a build system OS change may mean that the
JDK7 binary bundles may support fewer OS releases.
So this is a bit of a status report, and a bit of a heads up.
Hopefully most people will cheer over this news, but we'll see.

Solaris

On Solaris we have already moved to Solaris 10 as the base OS, which
means that the build bundles will no longer run on Solaris 8 or Solaris 9
systems.
We will also be moving from the Sun Studio 11 compilers to the
Sun Studio 12 compilers.
Sun Studio 12 is FREE for SDN members
(registration is free too).
Keep in mind that this doesn't mean that you can't build with Sun Studio 11,
just that we will focus on using Sun Studio 12.
At some point using older tools or OS releases to build the OpenJDK may become an issue,
but it is not our intent to create these issues.
There are some places in the JDK where we would like to depend on some
newer features of the OS being available, so there are no promises
that the OpenJDK7 sources will stay buildable on Solaris 8 or 9, but
currently they are.

The Solaris Makefile changes for Sun Studio 12 (SS12)
will include changing to new -xarch options
as described in the
"What's New In The Compilers" document.
The old -xarch options will continue to work fine,
but generate warning errors, and
so the change to the new options is to avoid the warning errors.

Note that since we still use the assembler that comes with the Solaris
system at /usr/ccs/bin/as, we still have to supply it with the
old option spellings.

We did run into two build issues so far:

Using -xO4 built .o files with dtrace is giving us some problems.
We suspect the optimizer may have tossed some C++ methods that exist only
for dtrace probes. We had to change -xO4 to -xO3 -g on three
files in hotspot.

We had to revert the C++ debug format from Dwarf2 to stabs with the option
-xdebugformat=stabs.
We were getting some ld errors on some Elf sections during link time.
We suspect this is a known problem with Elf COMDAT sections and will be watching for a fix.

It may be a while before we push these Makefile changes to the OpenJDK
repositories.
Changing compilers with the JDK on any platform is not as trivial a task as
people might think.
With Solaris and the Sun Studio compilers, we have an advantage, knowing
the team doing the compilers.
But with any compiler change, our biggest issue becomes performance and correctness.
Not so much the performance and correctness of the C/C++ generated code, but the combination
of this C/C++ code with the Hotspot generated code.
It's not unusual to have bad runtime interactions
between the C/C++ generated code, and the Hotspot generated code, on any
platform and with any compiler revision.

So the next steps will involve running formal benchmarks to verify that
we haven't regressed in performance. A somewhat difficult task given the
moving target that OpenJDK7 is right now.

Linux

We already know that building the OpenJDK with different Linux releases
and gcc compiler versions is working, so with Linux we just need to advance
to a slightly newer Linux release as the base OS, and one that gives us the largest set
of deployed targets.
We still run the risk of performance and correctness issues like with Solaris, so
the same benchmark exercises will need to be done.
This will mean that the JDK7 binary bundles will no longer run on some
older Linux systems.
That doesn't mean it can't be built for these versions, just that the
binary bundles we supply may be limited in the Linux releases it supports.

Windows

There is some efforts going on to see about changing to the
Visual Studio .NET 2008 compilers, and potentially Windows XP as
the base OS for 32bit.
Again, dito on the performance and correctness issues.
This will mean that the JDK7 binary bundles will no longer
work on Windows 2000.

Official Supported Configurations

The Official JDK6 supported configurations
are those configurations that we have tested the JDK6 builds on.
The official supported list for JDK7 will need to be adjusted of course,
certainly Solaris 8 and Solaris 9 support for JDK7 will be removed.

Other Configurations

The OpenJDK sources can be built on many more systems as documented in the
OpenJDK Build README.
The intent with the OpenJDK is to allow for it to be built on as many
configurations as possible, but that does not necessarily mean that
a configuration will become any kind of officially supported JDK7 configuration.
The OpenJDK
project is an open-source project, and to date,
binary builds have not been provided.

Other architectures like IA64 or PowerPC are or may be considered "ports",
depending on the need for changing the Hotspot VM to generate code for a
different architecture.
There are several "ports"
being talked about on the OpenJDK porters alias, see
the OpenJDK Mailing Lists.
Recently, changes to Hotspot were pushed into the OpenJDK source repositories that
allowed for Linux SPARC builds of Hotspot, see the changeset
Open-source hotspot linux-sparc support.
Email exchanges on the distro-pkg alias indicate people are building on
Linux IA64, not sure if they have been successful or not, I have no
idea how IA64 this would be.
Of course, successfully building is only step 1, the next step is to see if
it works, and works reliably.
The point being that many people are taking the OpenJDK sources or IcedTea
and building on many configurations.

The funding needed to take on and support a new official
configuration is considerable.
We hope that the OpenJDK developers contribute back the changes made to
port or build on any configuration.
But adding a new configuration to the official JDK7 build configuration list
is a high level decision.