AArch64 in JDK 9?

[Vladimir Kozlov]

On 4/19/14 12:23 PM, Vladimir Kozlov wrote:
> On 4/19/14 1:17 AM, Andrew Haley wrote:
>> Hi,
>>
>> On 04/17/2014 11:16 AM, Volker Simonis wrote:
>>>
>>> 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.
>>
>> OK.
>
> Yes, until JEP is funded we can do nothing from Oracle side. It could take time based on ppc-aix port experience.
>
>>> - 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.
>>
>> Sure, I was planning to do that anyway.  There is one thing I don't
>> understand how to do, though.  jcheck wants bug IDs for all changes,
>> right?  So does that mean that you have to create bug IDs when you
>> create the staging repository?

It may be was not clear but the official staging repo is created by Oracle because the forest should contain closed 
repository. And it is created after JEP is approved/funded.
You can have your own staging repo for your patches preparation and testing. But you will have to manage it yourself.

Regards,
Vladimir

>
> Staging repository is created by cloning jdk9-dev forest. After that any changeset which will be pushed into that repo
> have to have a valid changeset descriptor/comment:
>
> http://openjdk.java.net/guide/producingChangeset.html
>
> You have to file a separate bug in JBS for each patch, preferable with "AArch64:" prefix in bug's subject. Here is what
> we had for first ppc64 changes:
>
> https://bugs.openjdk.java.net/browse/JDK-8016476
> https://bugs.openjdk.java.net/browse/JDK-8016491
>
> It also helped a lot with ppc-aix port when SAP prepared list of all patches they wanted to push so we could preview
> them and estimate needed efforts during JEP review:
>
> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/df79d76c17ab/ppc_patches/
>
> It was also important to break the port into separate small/medium patches for easy review and testing.
>
> Regards,
> Vladimir
>
>>
>>> 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
>>> https://wiki.openjdk.java.net/pages/viewpage.action?pageId=13729959)
>>> 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).
>>
>> Right.
>>
>>> 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.
>>
>> Sure, I get that.  I'll have to go over our code changes to see if
>> anything affects non-AArch64 ports.
>>
>>> 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
>>> project done:)
>>
>> Well, yes.  And this is going to get more common, I hope, so we need
>> to establish a smooth pathway to help people get ports in.
>>
>> One interesting challenge here is that there really isn't much AArch64
>> hardware around for other people to test on, but I hope that it will
>> be common enough later in the year.
>>
>>> If you have any questions or if there's anything I can do please don't
>>> hesitate to let me know.
>>
>> OK, I'll remember that.
>>
>> Thanks,
>> Andrew.
>>