[aarch64-port-dev ] Summary of recent jdk7 updates pulled from upstream jdk8

[Andrew Dinn]

On 26/11/14 11:39, Andrew Haley wrote:
> On 11/26/2014 11:07 AM, Andrew Dinn wrote:
>> Either we retain the AArch64 code in its
>> own icedtea7-forest-aarch64 forest or we push the changes back up into
>> icedtea7-forest. I think we should do the latter.
> 
> Yes.  Especially since there should be no significant difference
> to shared code.

That's why I highlighted the SHA change. We could add support for SHA in
the shared code and then implement it in AArch64. But that might well
pose a risk for the other builds and, at the least, would change the
command line by adding support for the UseSHA flags.

>> Firstly, it means that any forked maintenance release of
>> icedtea7-forest will automatically fork a maintenance version of the
>> aarch64 code. Secondly, it would allow us to continue using the
>> icedtea7-forest-aarch64 forest as a staging repo where we can test
>> changes backported from JDK8/9. Any thoughts?
> 
> We need http://hg.openjdk.java.net/aarch64-port/jdk7u/hotspot to be
> updated to the same level, but without the IcedTea-local patches.  I
> would hope that these are confined to shared code, so it shouldn't be
> a huge job.

Hmm, now you mention this? :-)

I am afraid that your hope is a tad misplaced. I did actually start the
backport by massaging a hotspot tree derived from upstream oracle
jdk7u/hotspot as well as one derived from our icedtea7-forest/hotspot.
That's because I originally started off trying to produce a hotspot
which would work with our other jdk7u derived repos located under
aarch64-port/jdk7u. So, I applied patches to the jdk7u-derived tree
first and then to icedtea7-forest-derived tree.

I continued applying changes in parallel for (roughly) the first 80
change sets. That means that I have (on my machine) a tree derived from
oracle's upstream jdk7u/hotspot which includes parallel changes to up to
change set 5656 "use the correct return value from the VM resolve call"
of the latest icedtea7-forest-aarch64. Unfortunately, I did not achieve
this at no cost. I had to carefully apply a lot of the patches by hand
because of niggling minor differences in the non-shared code. So,
eventually, I just gave up maintaining the jdk7u-derived tree. That
means that the last 35 change sets have only been applied in
icedtea7-forest-aarch64.

I could revive this tree and patch it to obtain a hotspot tree which, in
theory, could be used to replace aarch64-port/jdk7u/hotspot. I say 'in
theory' because, while this ought to build and run with the code
currently located in the rest of the aarch64-port/jdk7u/ forest, it may
be that we need to pull in various changes from upstream jdk7u, either
into this modified hotspot or, indeed, into the other parts of the forest.

Before I do that I need to ask why we need to have an AArch64 jdk7
forest tree derived from upstream jdk7u as well as one derived from
icedtea7-forest? Surely one is enough? Maintaining two trees is not
going to be trivial. Is there  a good justification for doing it?

regards,


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