On Wed, 9 Mar 2022 19:03:16 GMT, Anton Kozlov <akoz...@openjdk.org> wrote:
>> Johannes Bechberger has updated the pull request incrementally with one >> additional commit since the last revision: >> >> current_thread_wx -> ThreadWX > > https://github.com/openjdk/jdk/compare/master...478ec1a7ca2c72e5916b28613a4875aa2ee1a793 > touches more places than a targeted change in ThreadWXEnable... I'm not sure > the real nesting is required for a thread that is not registered properly > with VM. The initial state is always assumed for the NULL Thread. The > SafeFetch assembly does not do up-calls to VM. I don't see why we'd need > runtime tracking of WX state. The state is either WXExec for SafeFetch > assembly, or unknown -- which we assume to be WXWrite regardless of approach > taken. > > Nesting was implemented to reduce the amount of changes in JVM (yes, WX code > scattered around the VM less than it could be :)), but it is possible to > avoid runtime WX tracking if you always know the state, like we do if Thread > == NULL. @AntonKozlov can you give us please a bit more background about the wx state stuff? - Why don't we just switch it on once, for a thread that conceivably may call into generated code, and be done with? Why is this fine granular switching even needed? I find it difficult to imagine an attack vector that exploits having this always enabled for a thread. After all, we have to mark code cache with MAP_JIT already, so it is not like we can execute arbitrary memory ranges. - Related to that, how much does this call cost? Is this a runtime call into the pthread library or does it get inlined somehow? Because things like SafeFetch are trimmed to be super cheap if the memory can be accessed. Doing a pthread call on every invocation may throw off the cost benefit ratio. - Why and where do we need nesting? This would be so much easier if we could just not care. ------------- PR: https://git.openjdk.java.net/jdk/pull/7727
