RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2]

Coleen Phillimore coleenp at openjdk.java.net
Fri Jan 8 13:43:05 UTC 2021


On Fri, 8 Jan 2021 06:52:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix grammar
>
> src/hotspot/share/runtime/handles.hpp line 293:
> 
>> 291: // ResetNoHandleMark is called in a context where there is an enclosing
>> 292: // NoHandleMark. A thread in _thread_in_native must not create handles so
>> 293: // this is used when transitioning via ThreadInVMfromNative.
> 
> This comment still doesn't clearly (to me) explain the use of RNHM. Basically it is intended to "disable" a NHM further up the stack but why do we not force the caller up the stack to correctly scope the NMH? This seems to be a way to allow sloppy coding further up the stack, or worse it allows code to be called that might use Handles completely unexpectedly wrt the code up the stack. Should a NHM not mean "this code and all code called from it must not use Handles"?
> 
> And can't this be used in a range of contexts not just this ThreadInVMFromNative transition?
> 
> Thanks,
> David

Yes so the NHM does mean "this code and all code called from this must not use handles" which is why it appears in the JNI_LEAF and JVM_LEAF.  Handles and oops are not safe in VM code whose state is _thread_in_native.
So the interesting scenario here is:

JNI_LEAF(some function) {
  do some things that don't allow oops or Handles (the NHM will cause an assertion to help make sure this is the case)
  // Oh rats, we need to go into the VM maybe conditionally
  ThreadInVMFromNative tivm;
   // Now handles are cool.
}
This change embeds the ResetNoHandleMark in the ThreadInVMFromNative so that all the callers don't require it.

The caller up the stack is the JNI_LEAF generally where we generally want NoHandleMark.

The transitions from Java to VM don't require this because my n+1 change lifts the no Handle restrictions.  This is the only case where this pattern is needed in the callers.  My goal with this is to reduce the intellectual noise required to read this and figure out why it's needed that is littered around the source code.

I'm not sure what to say in this comment that explains this better, please suggest better wording.

-------------

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


More information about the hotspot-dev mailing list