RFR: 8262952: [macos_aarch64] os::commit_memory failure

[Gerard Ziemski]

On Mon, 10 May 2021 09:43:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> On x86_64 macOS the following sequence works just fine:
>> 
>> attempt_reserve_memory_at(executable=false)
>> commit_memory(executable=true)
>> 
>> however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it.
>> 
>> Please note, that:
>> 
>> attempt_reserve_memory_at(executable=true)
>> commit_memory(executable=false)
>> 
>> works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later.
>> 
>> Passes Mach5 hs-tier1,2,3,4,5 tests
>
> src/hotspot/os/bsd/os_bsd.cpp line 1708:
> 
>> 1706:       // On macOS aarch64 MAP_JIT is required if we want to commit an executable chunk
>> 1707:       // later, so always reserve executable memory right from the start
>> 1708:       MACOS_AARCH64_ONLY(| MAP_JIT);
> 
> Is this the right way to do it? Where do we ever map memory we want to use for code generation, but not ask for exec permission? Is that a bug?

Inside the hotspot VM code we seem to be doing the right thing, however, in the test, i.e. `test/hotspot/gtest/runtime/test_os.cpp` we ask for regular memory, then try to commit a chunk with elevated exec privileges, which seems to work on all other platforms, except aarch64 macOS.

The alternative, would be to fix the test in question, but since this scenario works fine on all the other platforms, I figured the proposed way to handle it in the VM  would be the preferable way to fix it, so future test writers do not need to know this particular platform behavior difference and risk getting it wrong again.

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

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