[aarch64-port-dev ] Intro to icedtea7-forest-aarch64 port

[Andrew Dinn]

Here is an explanation of what has been going on regarding the
jdk7-aarch64 port and why. More notes will follow detailing work done so
far as detailed below.

Why are we porting Icedtea7 to AArch64?
---------------------------------------

The code in http://hg.openjdk.java.net/aarch64-port/jdk7u/hotspot/ is
used to build the VM employed in current releases of Icedtea7 on
AArch64. However, it is not really a JDK7 VM. It is (modulo a few
details) essentially the same implementation as the jdk8-aarch64 hotspot.

This is a problem because eventually jdk8-aarch64 is going to diverge
far enough from jdk7 that we will not be able to use the jdk8 derived VM
to support our JDK7 icedtea7 releases. In fact, we are already in a
position where we cannot pull upstream jdk8-aarch64/jdk8u changes due to
incompatibilities in dynamic method execution. We cannot really live
with the status quo of an increasingly out of date JDK7 (amongst other
things RHEL7 still needs to use it as part of its build process for many
years to come).

So, in order to be able to continue releasing Icedtea7 on AArch64 we
need to perform and the maintain a full port of JDK7 to AArch64. I have
spent the last few weeks back-porting our AArch64 code into the
icedtea7-forest. The intention is to produce an icedtea7-forest which
includes aarch64-specific code in its hotspot tree and which can be used
to build icedtea7 on AArch64 architectures.

Where are we so far?
--------------------

Backporting has already been started based on a cloned version of the
icedtea7-forest repo (changeset 5556 SHA1 Id: b517477362d1 at the point
where the PPC code was merged) and the aarch64 port jdk7u repo. The plan
involves the following steps:

  1 change shared code in icedtea7 hotspot to allow for the presence of
the AArch64 port

  2 import the cpu- and os_cpu-specific code found in
aarch64-port/jdk7u/hotspot into the icedeta7/hotspot tree

  3 rework the imported code to conform to the jdk7 design

  4 build and debug the resulting code to the point where it can run
some basic smoke tests (java Hello; javac Hello.java; eclipse)

  5 perform full testing (specJVM, jcstress, TCK etc) and QE of the
build, fixing any bugs which turn up

  6 pull in any outstanding changes from upstream icedtea7 and also
apply outstanding fixes/updates which need backporting from jdk8

  7 merge the working aarch64 build up into the icedtea7-forest and
ensure it does not break any of the other builds

I have now performed steps 1 to 4 (n.b. step 4 has been performed using
both the x86-aarch64sim hybrid build and mustang hardware -- modulo no
eclipse on mustang).

n.b. steps 5, 6 and 7 can all sort of happen in parallel to some degree.
*help from Linaro* on testing and patching would be much appreciated :-)

n.b.b. we have a choice for step 7. let's assume we have our latest port
in a public icedtea7-forest-aarch64 repo somewhere. we can

EITHER

  maintain icedtea7-forest-aarch64 as a downstream copy of
icedtea7-forest and pull in upstream changes, leaving upstream untouched

OR

  push changes up into icedtea7-forest and use icedtea7-forest-aarch64
merely as a staging repo

I would prefer option 2 as it means icedtea7 builds all just run off the
same repo. Does anyone else have any views?

What comes next?
----------------

I will move my (currently) Red Hat-private icedtea7-forest-aarch64
forest onto a public server. I don't yet know where it is going. It
probably needs to be on the same server as the icedtea7 forest
(icedtea.classpath.org).

I will publish the sequence of changesets needed to arrive at this point
to the aarch64-port list. This is i) to record what the code changes
made so far and ii) ensure that there are more eyeballs verifying those
changes.

Once we have a public icedtea7-forest-aarch64 forest I think we should
configure it so that changes go to this list. Anyone have any other
opinions on this?

regards,


Andrew Dinn
-----------