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

Coleen Phillimore coleenp at openjdk.java.net
Mon Jan 25 19:14:48 UTC 2021

On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:
>>> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
>>> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
>>> 87:   Thread::WXWriteFromExecSetter wx_write;
>> Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?
> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.

Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
class ThreadInVMfromNative : public ThreadStateTransition {
  ResetNoHandleMark __rnhm;

We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.


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

More information about the security-dev mailing list