JEP proposal: "PowerPC/AIX Port"

[Volker Simonis]

Hi Alan,

thank you for reviewing our JEP proposal.
Please find my answers inline:

On Tue, Jan 15, 2013 at 9:32 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 15/01/2013 16:56, Volker Simonis wrote:
>>
>> Hi,
>>
>> before officially submitting this JEP proposal I want to post it here
>> for discussion.
>>
>> Please notice that the focus of this JEP is not the porting effort
>> itself which has been mostly completed [1] but rather the integration
>> of the ports into the JDK8 main repository.
>>
>> As always, any further comments, suggestions or questions are
>> highly welcome.
>>
>> Thank you and best regards,
>> Volker
>>
>> [1]: http://openjdk.java.net/projects/ppc-aix-port
>
> I think this needs a "Risks and Assumptions" and "Dependencies" sections to
> clearly list the assumptions and dependencies (some of these are in the
> current description).
>

As stated in the JEP, we don't expect any major "Risks" as all the code we
propose for integration are backports of commercial Java offerings by
IBM and SAP which run in production environments since years on both,
the newly proposed platforms as well as on the platforms currently
supported by the OpenJDK.

The only "Dependencies" are in fact the resources and the commitment
provided by Oracle. Considering the current infrastructure deficiencies we
really need support from Oracle colleagues for everything starting with
the creation of BugIDs through the reviewing of changes up to the
Oracle-internal testing (JPRT) and final committing. I therefore suppose
this JEP needs funds at least by the "HotSpot" and the "Core Libraries"
groups.

> In the "Motivation" section it includes the statement "Refactor and
> modularize the OpenJDK source base to simplify future ports" but that seems
> a bit different to the goal of integrating the port.
>

Well that depends on how the integration will be done and that mainly
depends on the liking of the corresponding source code owners. Just to give
a small example: in HotSpot  we have a method 'os::vm_page_size()' but on
AIX it is possible that the thread stacks have a different memory page size than
heap memory. So we could either fix the few call sites of 'os::vm_page_size()'
which really need the stack page size with "ifdef AIX" or we could refactor the
whole code and introduce a new method 'os::vm_stack_page_size()'.

There are many of these examples and I think every single one should be
solved pragmatically based on common sense.

In general you're right: the main focus of the JEP is absolutely the
integration of
the port. In the case where we would have to decide to either
instantly integrate
a change "as is" or wait with the integration until a bigger
refactoring has taken
place we would always choose to integrate. In some cases it may nevertheless
make sense to do some of the refactoring as part of the integration.

> As I read the JEP then I don't see any high-level proposal as to how this
> might go in. You might remember the phased approach that was taken with the
> Mac port.
>

Actually I don't exactly remember the approach taken for the Mac port and I'll
be happy for any experiences you could share with us. But of course the
port integration will not happen in one big change.

- The first step would be to integrate the HotSpot changes:

Currently we have for example about 80 changesets on top of the HotSpot
repository.I think a good estimation for the integration of our changes into
the hotspot tree would be to tailor several bigger changesets (i.e. 20-30) which
can be reviewed and committed one by one (notice that most of these
'bigger' changes will not affect current platforms at all, because
they only contain
ppc64/AIX relevant code in the new platform-dependent files and subdirectories).

- The second step would be the class library changes

After the HotSpot can successfully build on the new platforms, we can start
with the integration of the class library changes. There will be less changes
with a lower complexity compared to the HotSpot changes and the changes
will be much more independent of each other so the review process
should be easier and easier to parallelize (i.e. AWT changes are independent
of NIO changes and can be done in arbitrary order). I don't expect that the
overall complexity in the class libraries area will be bigger compared to the
MacOS port (e.g. we don't need a complete new graphics stack).

> The testing section does not make it clear if the current OpenJDK tests will
> be updated to work on these new platforms.
>

Sure! We've internally already run the OpenJDK tests (i.e. the jtreg regression
test) and we will soon post regular test reports of our nightly builds.

> Not JEP related but is there is jdk8 based forest with the proposed changes
> that someone could browse? It doesn't appear that ppc-aix-port/jdk8 is used.
> I did find ppc-aix-port/jdk7u but it doesn't appear to have been sync'ed up
> with jdk7u since 7u6 (I see there is a lot of recent activity on the hotspot
> repo, very little on the jdk repo for a few months).
>

You're right. We've cloned 7u6 and ported HS23. Currently we're running JCK
tests on our ports to have a certified version of Java 7 on our
porting platforms.

The next step will be to lift our HotSpot port to HS24 and move our complete
Java 7 port to the current version of jdk7u-dev.

Finally we will lift our HotSpot port to the current HS version in the
hsx-repository and the complete port to the actual jdk8 version.

We expect to complete this work by April. That's why we proposed 2013/Q2
as the start date of the project.

> Also not JEP related but what timeframe are you hoping to get this into the
> main line if funded? The start date in the JEP is proposed as 2013/Q2 and
> jdk8 will be well past Developer Preview at that point.
>

We don't expect to get into the first jdk8 release but we hope to make it
into the first regular jdk8 update (i.e. jdk8u2 or however it will called).

> -Alan.