8253795: Implementation of JEP 391: macOS/AArch64 Port

[AntonKozlov]

Please review the implementation of JEP 391: macOS/AArch64 Port.

It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64.

Major changes are in:

• src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
• src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
• src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
• src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issues

• JDK-8253795: Implementation of JEP 391: macOS/AArch64 Port
• JDK-8253816: Support macOS W^X
• JDK-8253817: Support macOS Aarch64 ABI in Interpreter
• JDK-8253818: Support macOS Aarch64 ABI for compiled wrappers
• JDK-8253819: Implement os/cpu for macOS/AArch64
• JDK-8253839: Update tests and JDK code for macOS/Aarch64
• JDK-8254941: Implement Serviceability Agent for macOS/AArch64
• JDK-8255776: Change build system for macOS/AArch64
• JDK-8262903: [macos_aarch64] Thread::current() called on detached thread

Reviewers

• Erik Joelsson (@erikj79 - Reviewer) ⚠️ Review applies to 5add926
• Magnus Ihse Bursie (@magicus - Reviewer) ⚠️ Review applies to 5add926
• Phil Race (@prrace - Reviewer) ⚠️ Review applies to ab72613
• Chris Plummer (@plummercj - Reviewer) ⚠️ Review applies to 0c2cb0a
• Stefan Karlsson (@stefank - Reviewer) ⚠️ Review applies to f6fb01b
• Gerard Ziemski (@gerard-ziemski - Committer) ⚠️ Review applies to ab72613
• Andrew Haley (@theRealAph - Reviewer) ⚠️ Review applies to 5add926
• Monica Beckwith (@mo-beck - Author) ⚠️ Review applies to 5add926
• Ludovic Henry (@luhenry - Author) ⚠️ Review applies to 5add926

Contributors

• Vladimir Kempik <vkempik@openjdk.org>
• Bernhard Urban-Forster <burban@openjdk.org>
• Ludovic Henry <luhenry@openjdk.org>
• Monica Beckwith <mbeckwit@openjdk.org>

Download

To checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200
$ git checkout pull/2200

To update a local copy of the PR:
$ git checkout pull/2200
$ git pull https://git.openjdk.java.net/jdk pull/2200/head

[magicus]

Build changes still look good. Hope you can get this done now! :)

[AntonKozlov]

No, no, no! I am not suggesting you change anything else, just that
you do not define contentless macros. You might as well define it
to be something, and true is a reasonable default, that's all. It's
not terribly important, it's just good practice.

I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

Sorry, I missed your reply.

R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change.

The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example

jdk/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp

Line 35 in 8c1ab38

#define SUPPORTS_NATIVE_CX8

and

jdk/src/hotspot/share/runtime/mutexLocker.cpp

Line 137 in b7b391b

#ifndef SUPPORTS_NATIVE_CX8

But

jdk/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp

Line 59 in 8c1ab38

#define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS false

and

jdk/src/hotspot/share/runtime/arguments.cpp

Line 1540 in b23228d

if (COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS) {

[AntonKozlov]

/issue 8262903

[openjdk]

@AntonKozlov
Adding additional issue to issue list: 8262903: [macos_aarch64] Thread::current() called on detached thread.

[drej1]

Hi @drej1, thanks for making a comment in an OpenJDK project!

All comments and discussions in the OpenJDK Community must be made available under the OpenJDK Terms of Use. If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please Use "Add GitHub user drej1 for the summary.

If you are not an OpenJDK Author, Committer or Reviewer, simply check the box below to accept the OpenJDK Terms of Use for your comments.

• I agree to the OpenJDK Terms of Use for all comments I make in a project in the OpenJDK GitHub organization.

Your comment will be automatically restored once you have accepted the OpenJDK Terms of Use.

[VladimirKempik]

Hello That depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

…

23 марта 2021 г., в 16:39, drej1 ***@***.***> написал(а): So, where are we up to now? Are we done yet? Hello we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17 Hi there, will this be also supported backwards? To support java11 LTS version? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQS2KRC6LT7BKA37RMS5I5DTFCKX7ANCNFSM4WO4SQXQ>.

[theRealAph]

[ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

[VladimirKempik]

[ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

[mo-beck]

[ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

[theRealAph]

[ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

[AntonKozlov]

The JEP was targeted to JDK17. So I propose to integrate this.

Thank you all for the reviews, suggestions, discussions, and support!

[AntonKozlov]

/integrate

[openjdk]

@AntonKozlov
Your change (at version d362996) is now ready to be sponsored by a Committer.

[VladimirKempik]

/sponsor

[openjdk]

@VladimirKempik @AntonKozlov Pushed as commit dbc9e4b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.