[jdk11u-dev] RFR: JDK-8253947: Implementation: JEP 388: Windows AArch64 Support

[Reka Kovacs]

On Mon, 23 Aug 2021 22:28:06 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This is a more recent version of https://github.com/openjdk/jdk11u/pull/2.
>> 
>> Changes since then:
>> - [JDK-8254634](https://bugs.openjdk.java.net/browse/JDK-8254634) (backport of [Build failure with VS 2019 (16.5.0) due to C2039 and C2873](https://bugs.openjdk.java.net/browse/JDK-8241087)) was removed, as it had been committed separately.
>> - [JDK-8269391](https://bugs.openjdk.java.net/browse/JDK-8269391) (backport of [AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter](https://bugs.openjdk.java.net/browse/JDK-8265756)) was added.
>> - [JDK-8271095](https://bugs.openjdk.java.net/browse/JDK-8271095) (backport of [C4530 was reported from VS 2019 at access bridge](https://bugs.openjdk.java.net/browse/JDK-8263136)) was added.
>> - [JDK-8271002](https://bugs.openjdk.java.net/browse/JDK-8271002) (backport of [AArch64: Fix MacroAssembler::get_thread convention](https://bugs.openjdk.java.net/browse/JDK-8261072)) was added.
>> - [JDK-8272181](https://bugs.openjdk.java.net/browse/JDK-8272181) was added, containing the Windows/AArch64 related part of [JDK-8271571](https://bugs.openjdk.java.net/browse/JDK-8271571) (backport of [AArch64: Backtracing broken on PAC enabled systems](https://bugs.openjdk.java.net/browse/JDK-8266749)), necessary for a correct build.
>> - Various small merge conflict resolutions.
>> 
>> Similarly to how it was done on tip, we have incorporated parts of [JDK-8253015: Aarch64: Move linux code out from generic CPU feature detection](https://bugs.openjdk.java.net/browse/JDK-8253015) by @AntonKozlov into the [JDK-8253947: Implementation: JEP 388: Windows AArch64 Support](https://bugs.openjdk.java.net/browse/JDK-8253947) commit.
>> 
>> Please let me know how I can make the review process easier / faster.
>
> Hi,
> I have a suggestion: For this series of backports you can use dependent PRs. That is, you create a standard PR for the first change. Then, create the next backport to the branch "pr/#<number of first PR>" which will appear in the repo after the first PR is opened. This way, the whole chain is based upon each other and can be reviewed in parallel.
> 
> You have to integrate the PRs in order then. Once a PR is merged, its successor will automatically be updated to target the master branch.

@RealCLanger thanks for the suggestion. I'm opening a chain of PRs for the last few commits in the following order: #274 - #299 - #301 - 8254827 - 8252114. I liked the simplicity of most of the PRs going in independently, but now in the end chaining makes a lot of sense.

-------------

PR: https://git.openjdk.java.net/jdk11u-dev/pull/222