[aarch64-port-dev ] [8u] RFR (M) 8228400: Remove built-in AArch64 simulator

Hohensee, Paul hohensee at amazon.com
Tue Aug 6 17:23:56 UTC 2019


You might do the push to jdk8u-dev in more than one step. It's zero risk to push cpu/aarch64, os_cpu/linux_aarch64, the equivalent agent directories,  and platform-specific build files, so you could do that first. That's the vast majority of LOC. Next would be common build code changes, also low risk and (easily) testable. Finally would be changes to shared code.

Thanks,

Paul

On 8/6/19, 8:30 AM, "aarch64-port-dev on behalf of Aleksey Shipilev" <aarch64-port-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:

    On 8/6/19 3:12 PM, Andrew Haley wrote:
    > On 8/6/19 1:33 PM, Aleksey Shipilev wrote:
    > 
    >> I thought we wanted to merge the entirety if
    >> aarch64-port/jdk8u-shenandoah in one swoop.
    > 
    > True. It might well be the easiest thing to do, but OTOH I'm not sure
    > it'll make for an easy review.
    > 
    >> The webrev above is the difference between
    >> aarch64-port/jdk8u-shenandoah and jdk8u upstream. It is still not
    >> that close to something I would be comfortable to propose.
    > 
    > Oh, I see; I didn't understand what you were trying to do. I thought
    > it was all part of the aarch64 backport, hence my bafflement.
    
    My goal is to make aarch64-port/jdk8u-shenandoah vs jdk8u difference as narrow as possible, before
    the heat of the actual review whenever we propose aarch64-port/jdk8u-shenandoah for inclusion to
    jdk8u. I usually invite everyone to look through those autogenerated webrevs and chip away
    differences one by one. When we were doing Shenandoah upstreaming, it was by far the sanest way to
    go about bulk contribution. (The alternative is juggling staging repositories and/or 100 KLOC
    webrevs, good luck with that.)
    
    There are a few minor Shenandoah 8u cleanups pending, and there is also the major ones (LRB and
    nofwdptr), which should trim out the significant part of it. None of this changes the processes we
    have already: everything Shenandoah-related comes with Shenandoah integrations, after Shenandoah
    testing :)
    
    -- 
    Thanks,
    -Aleksey
    
    



More information about the aarch64-port-dev mailing list