[aarch64-port-dev ] [jdk11u] 8253947: Implementation: JEP 388: Windows AArch64 Support

[Andrew Haley]

On 03/10/2020 20:57, Vladimir Kempik wrote:
>
>>I warn you now that you may never get approval to backport this
>>stuff to mainline jdk11u because it's too disruptive.
>
> Shenandoah?

Shenandoah doesn't give blanket permission for any and every backport
to be done. There are differences between Shenandoah and an
AArch64/Windows backport. The first three I think of are:

  1. Over time, a release branch becomes more and more stable, and
  fewer and few backports are accepted. JDK 11u is getting well into
  middle age.

  2. Shenandoah had been maintained in a fairly stable out-of-mainline
  repo for a very long time. It was not in any way new when it was
  merged.

  3. The Shenandoah backport into 11u provably had no effect unless it
  was enabled.

> Could you also please suggest us about jep-391.

Same as above.

> Does Redhat would like to see macos-aarch64 support in openjdk11, or
> its better to leave users with Rosetta translator?

I'm not sure what Red Hat's opinion might be, or even how I'd find
out. However, I do know that stability is the first priority for the
JDK 11u project, which is why we went to such extraordinary lengths to
ensure we didn't break anything with the Shenandoah backport.

In addition, there will be ways for users to get JDK 11 / MacOS /
AArch64 even if it's not in the man 11u tree.

> If jep-391 is welcomed into 11u, then it will need some parts of
> windows-aarch64 port (x18 exclusion).

I see.

Note that I am *not* ruling out AArch64 support in JDK 11. If it can
be done cleanly and safely that will be great. However, to begin with,
it will not go into OpenJDK 11u. The stability of the main release
branch of OpenJDK is far too important for it to be broken by an
untested new port.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671