Shenandoah and aarch64

[Hohensee, Paul]

My approach might be of interest. I used the icedtea 3.8 source snapshots as the basis for the Amazon 8u aarch64 port, so there was no history to preserve. I did that because I wanted as-shipped source to piggy-back off RedHat's testing (just the way we all used to piggy-back off Oracle testing :)), and didn't want to deal with transient bugs in the dev repos. Here's what I did.

First pushed all the platform-specific files, including hotspot/cpu/aarch64, hotspot/os_cpu/aarch64, etc. This was a nop wrt the other platforms, but got the lion's share of the code out of the way. Built and tested the result on linux-x64 (paranoia).

Then, found all the places in common code with an ifdef ARM64 and pushed those, since that was also a nop wrt to the other platforms. Built and tested the result on linux-x64 (more paranoia).

diff'ed the remainder against jdk8u and eliminated the non-codegen/testing related icedtea code, which left very little to actually analyze for correctness. Added that under temporary ifdefs and enabled them one at a time, testing each on x64-linux (quite tedious) and pushed the result.

Then, built on AL2 and fixed all the gcc 8 issues. This was actually the vast majority (as in 99%) of the platform-independent changes. Built and tested the result on linux-x64 and pushed it.

Finally (and in parallel), tested aarch64. Had 2 or 3 bugs due to typos, but that went pretty smoothly.

'test' == run TCK, jtreg tests, jbb, etc.

Paul

On 7/15/19, 8:49 AM, "jdk8u-dev on behalf of Andrew John Hughes" <jdk8u-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:    
    
    On 14/07/2019 12:21, Roman Kennke wrote:
    >> On 12/07/2019 11:08, Andrey Petushkov wrote:
    >>> Azul fully supports this idea and would like to propose integration of aarch32 port as well, please
    >>>
    >>> Regards,
    >>> Andrey
    >>>
    >>>> On 11 Jul 2019, at 19:31, Hohensee, Paul <hohensee at amazon.com> wrote:
    >>>>
    >>>> We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I’d move Shenandoah first, since it presumably has hooks in platform dependent code which we’d have to work around if we did the aarch64 port first.
    >>>>
    >>>> Thoughts?
    >>>>
    >>>> Thanks,
    >>>>
    >>>> Paul
    >>>
    >>
    >> I agree, it would be good to finally see both ports in the main upstream
    >> repository. Shenandoah as well, though that should go to 11 first.
    >>
    >> The work should use a staging repository, as with JFR, so as to minimise
    >> disruption to the work on 8u releases.
    > 
    > For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It
    > seems to be the obvious choice because we already have it, and it is
    > supposed to only contain the actual difference between upstream jdk11u
    > and Shenandoah.
    > 
    > For jdk8, I am not quite sure. We do have shenandoah/jdk8. I believe it
    > probably would make sense to separate the aarch64 integration into 8u
    > from Shenandoah and not make Aarch64 wait for Shenandoah. In this case,
    > I think shenandoah/jdk8 would be good as staging for Shenandoah into
    > jdk8u too.
    > 
    > Roman
    > 
    
    When I refer to a staging repository, I mean something that could be
    pulled into the mainline jdk8u/jdk8u-dev i.e. something that has a
    series of changesets that have valid bug IDs and pass jcheck.
    
    I don't know how clean sh/jdk11 is now, but aarch64/jdk8u-shenandoah
    certainly isn't in that state.
    
    I would suggest starting with getting Shenandoah into 11u and aarch64
    into 8u (the two efforts can run in parallel). Once Shenandoah has
    soaked into 11u, it can be backported to 8u, by which time it should
    have aarch64.
    
    It'd be nice to get aarch64 into 7u too, but that's probably wanting too
    much :-)
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew