[aarch64-port-dev ] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port

Vladimir Kempik vkempik at openjdk.java.net
Wed Jan 5 15:50:07 UTC 2022


On Wed, 22 Dec 2021 07:17:15 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Backport of JEP-391 to jdk11u-dev
> The PR has two commits, one is simple copy of linux_aarch64 to bsd_aarch64. This will allow to see the difference applied to os_cpu against linux_aarch64 version.
> 
> Total 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
> JDK-8262896: [macos_aarch64] Crash in jni_fast_GetLongField

> Circeling back to the r18 issue mentioned here: [openjdk/jdk11u-dev#301 (comment)](https://github.com/openjdk/jdk11u-dev/pull/301#issuecomment-911998917) My understanding is that the current stable release of macOS (12.1 Monterey) should already be affected by this issue, as I haven't backported https://bugs.openjdk.java.net/browse/JDK-8274795 to jdk11 yet. Do you have some better reproducer other than running Intellij? Apparently none of the tier1 tests seem to trigger it.
> 
> Edit: The `release` build of this branch actually runs Intellij just fine.

that issue was gone after final version of r18 patch were included into jdk11u
in fact the issue was with c2 registers allocations and some #ifdef __APPLE__ not working as expected in ad files.

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

PR: https://git.openjdk.java.net/aarch64-port/pull/14


More information about the aarch64-port-dev mailing list