On Thu, 11 Nov 2021 13:58:06 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:

>> JNI Local handles can only be created by JavaThread (there's an assert in 
>> make_local) but the fields are added to Thread.
>> Move the fields to JavaThread and adding JavaThread* argument.
>> Also, the global freelist isn't very useful now that global JNI handles 
>> don't use JNIHandleBlock, so the locking that claims incorrectly to block 
>> for safepoint is removed.
>> Lastly, there's at least 3 places that duplicate pushing a new 
>> JNIHandleBlock to the thread for temporarily adding JNI local handles. These 
>> have been moved to common code with a JNIHandleMark object, moved from jvmci 
>> code.
>> The commits are separate to help reviewing, but the entire change has been 
>> tested together with tier1-6.
>> The commits in this change have been performance tested individually and 
>> together with no meaningful differences from mainline.
>
> Coleen Phillimore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add _is_running initialization.

Hi Coleen,

Cleanup looks good to me.

Thanks,
Patricio

src/hotspot/share/jfr/dcmd/jfrDcmds.cpp line 181:

> 179:   JNIHandleMark jni_handle_management(THREAD);
> 180: 
> 181:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(THREAD));

This method will call into Java below which already checks the thread is in vm 
so maybe this is not necessary. Even construct_dcmd_instance() has that assert.

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

Marked as reviewed by pchilanomate (Committer).

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

Reply via email to