On Wed, 3 Feb 2021 20:05:29 GMT, Anton Kozlov <[email protected]> wrote:
>> Thank you all for your comments regarding W^X implementation. I've made a
>> change that reduces the footprint of the implementation, also addressing
>> most of the comments. I'll revisit them individually to make sure nothing is
>> forgotten.
>>
>> The basic principle has not changed: when we execute JVM code (owned by
>> libjvm.so, starting from JVM entry function), we switch to Write state. When
>> we leave JVM to execute generated or JNI code, we switch to Executable
>> state. I would like to highlight that JVM code does not mean the VM state of
>> the java thread. After @stefank's suggestion, I could also drop a few W^X
>> state switches, so now it should be more clear that switches are tied to JVM
>> entry functions.
>
>> 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.
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?).
-------------
PR: https://git.openjdk.java.net/jdk/pull/2200
