RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[Gerard Ziemski]

On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> 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)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   support macos_aarch64 in hsdis

Changes requested by gziemski (Committer).

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390:

> 388:       store_and_inc(_to, from_obj, NativeStack::intSpace);
> 389: 
> 390:       _num_int_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches.

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 404:

> 402:     } else {
> 403:       store_and_inc(_to, from_obj, NativeStack::longSpace);
> 404:       _num_int_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 418:

> 416:     } else {
> 417:       store_and_inc(_to, (*from_addr == 0) ? (intptr_t)NULL : (intptr_t) from_addr, wordSize);
> 418:       _num_int_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433:

> 431:       store_and_inc(_to, from_obj, NativeStack::floatSpace);
> 432: 
> 433:       _num_fp_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 448:

> 446:     } else {
> 447:       store_and_inc(_to, from_obj, NativeStack::doubleSpace);
> 448:       _num_fp_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:

> 5269: //
> 5270: void MacroAssembler::get_thread(Register dst) {
> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;

The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ?

src/hotspot/os/posix/signals_posix.cpp line 1297:

> 1295:   kern_return_t kr;
> 1296:   kr = task_set_exception_ports(mach_task_self(),
> 1297:                                 EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC,

Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here?

src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:

> 91:     CPU_MARVELL   = 'V',
> 92:     CPU_INTEL     = 'i',
> 93:     CPU_APPLE     = 'a',

The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined?

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

PR: https://git.openjdk.java.net/jdk/pull/2200