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

[Mikael Vidstedt]

On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>>> I wonder if this is the right choice
>>> ...
>>> ```
>>> OopStorageParIterPerf::~OopStorageParIterPerf() {
>>> ...
>>> ```
>>> 
>> 
>> The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite.
>> 
>> I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped.
>> 
>> I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ...  are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests.
>> 
>> Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore.
>> 
>> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions.
>> 
>> Thank you!
>
> Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?).

You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific..

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

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