On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt <mik...@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
