On Tue, 5 Jan 2021 11:46:30 GMT, Ron Pressler <[email protected]> wrote:
>> This change allows JRT_LEAF functions to create Handles because it doesn't
>> need them but some code inside the VM needs Handles. There's a
>> NoSafepointVerifier in JRT_LEAF functions.
>> The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create
>> handles) but the transition ThreadInVMfromNative will reenable the
>> HandleMarks, so that all this code doesn't have to do it itself.
>> Tested with tier1-6.
>
> src/hotspot/share/code/compiledMethod.cpp line 707:
>
>> 705: Thread* thread = Thread::current();
>> 706: ResetNoHandleMark rnm; // Might be called from LEAF/QUICK ENTRY
>> 707: HandleMark hm(thread);
>
> Why was the `HandleMark` removed here? Is it not needed?
There are no Handles in this block. There are a lot of rogue HandleMarks
around because of PermGen. They don't do anything harmful, but they don't hold
any Handles either.
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 353:
>
>> 351: #define VM_LEAF_BASE(result_type, header) \
>> 352: TRACE_CALL(result_type, header) \
>> 353: debug_only(NoHandleMark __hm;) \
>
> Shouldn't `NoSafepointVerifier` be added here and then it can be removed from
> `JRT_LEAF`?
I don't want a NoSafepointVerifier in JNI_LEAF, and the equivalent fromNative
JVM_LEAF, which "calls" this. I only want it in JRT_LEAF. JNI_LEAF isn't
really a leaf, it often calls JNI functions that transition to the VM.
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 484:
>
>> 482: result_type JNICALL header { \
>> 483: VM_Exit::block_if_vm_exited(); \
>> 484: debug_only(NoHandleMark __hm;) \
>
> Why does `JVM_LEAF` need `NoHandleMark`?
JVM_LEAF comes from _thread_in_native so there shouldn't be oops or Handles.
It's really equivalent to JNI_LEAF. I tried to make sense of this in the CR
report, mostly so I'd remember what I was thinking.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1846
