AArch64 in JDK 9?
volker.simonis at gmail.com
Thu Apr 17 10:16:37 UTC 2014
I'd highly welcome your port in the main HotSpot tree!
Unfortunately I'm not the decision maker here, but I can try to
outline the steps we took to bring in our port and cc some people
(Iris, Azeem) who may know how to help.
- First of all we were told to and finally filed a JEP for the
integration project (in our case it was JEP 175: PowerPC/AIX Port -
http://openjdk.java.net/jeps/175). I think the main reason why this is
necessary is that such a project requires a certain amount of help
from Oracle and in order to get that you'll need to get your project
sponsored and funded. This all is formalized trough the JEP process.
- You'll probably need to have a "staging" repository as a mirror of
the current jdk9-dev forest. The staging repository will be kept in
sync with its mirror and additionally collect all your porting changes
as valid (i.e. in the sense of 'jcheck') and reviewed OpenJDK
changesets. Once your port is completed in the staging repository,
Oracle will probably want to do some bigger testing on it before the
complete port will be bulk integrated into the main repositories.
Notice that we actually had two staging repositories, one for jdk8 and
one for jdk9. I'd suggest you start with jdk9 and once you're finished
with that and depending on your wishes, you may also do the same with
jdk8u. But notice that Oracle is not following the HotSpot Express
model any more. This means that downporting your AArch64 port to jdk8u
will get continuously harder over time, even if you manage to get into
the main jdk9 repositories.
- After we got the our JEP approved and funded, we created a detailed
"Integration Plan" in the OpenJDK Wiki (see
where we outlined the different integration steps in some more detail.
I assume that you mainly only have HotSpot changes, so in one sense
your integration plan will be simpler. On the other hand, bringing in
HotSpot changes is the more intricate part of a port integration
because you can not check in changes yourself, even if you are a
committer, because of the known infrastructure problems (i.e. the need
to run all the changes trough the Oracle-internal JPRT test system).
There's also the problem that Oracle maintains some closed
repositories (e.g. their ppc ar arm ports) in parallel to the OpenJDK
repositories and changes in shared code may require modifications in
their closed ports. Therefore most changes to the "staging" repository
will have to be done by Oracle folks who can take care of their
proprietary port as well.
I'd therefore wait with the creation of a new repository as you
suggested until you synchronised with some of the Oracle folks. You
really need to find some good friends in the HotSpot group to get this
If you have any questions or if there's anything I can do please don't
hesitate to let me know.
On Mon, Apr 14, 2014 at 8:01 PM, Andrew Haley <aph at redhat.com> wrote:
> We'd like to propose contributing AArch64 support to the main HotSpot
> tree. SAP have already done this with PowerPC, so we hope to be able
> to follow the path they took.
> The changes to HotSpot outside the cpu/ and os_cpu/ directories are
> fairly minimal. There are quite a few changes we had to make to C1.
> C1's patching scheme is impossible on AArch64, which (except in some
> very restricted cases) does not allow the concurrent execution and
> patching of code. However, we can simply #ifndef these and do our
> own thing in our back end.
> We still have some performance tuning to do, and there are undoubtedly
> cleanups we'd like to make. Also, there are one or two remaining big
> ticket items, in particular vector support. However, the port works
> well, passes all its tests, and is IMO ready for the next stage.
> To begin with I'll create a JDK9 repository which tracks JDK9 with
> the minimum changes to shared code, then I guess the best thing would
> be for us to discuss the changes we need on this list.
> Does that make sense?
More information about the hotspot-dev