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