RFR: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark [v2]

[David Holmes]

On 11/01/2021 10:49 pm, Coleen Phillimore wrote:
> On Thu, 7 Jan 2021 22:29:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> Looks good to me!
>>
>> Thanks Dan and Patricio!
> 
>> What JNI_LEAF function does as you describe?
> 1.
> JNI_LEAF(void, JVM_RegisterNativeEntryPointMethods(JNIEnv *env, jclass NEP_class))
>    int status = env->RegisterNatives(NEP_class, NEP_methods, sizeof(NEP_methods)/sizeof(JNINativeMethod));
>    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
>              "register jdk.internal.invoke.NativeEntryPoint natives");
> JNI_END
> Also: JVM_RegisterProgrammableInvokerMethods, JVM_RegisterProgrammableUpcallHandlerMethods

Okay ... these really should not be "leaf" methods they are full JNI 
entries because they call a JNI_ENTRY method.

I vaguely recall some discussion around this ... issues with a JNI_ENTRY 
calling a JNI_ENTRY, so JNI_LEAF was used to get a lightweight entry 
point that simply called the real JNI_ENTRY method.

> 2. The real reason that I wrote this is patch is so that each of these ThreadInVMfromNative calls (from the compiler and JFR) don't need to also have ResetNoHandleMark.  The intention is to hide this detail so one doesn't need to try to figure out what this is when reading through the code. It is debug code, so after the transition, there is no need to have a NoHandleMark. My original intention is to hide this as much as possible since it's a weird artifact of our implementation of Handles.  It's noise, that I've always ignored until now.

My concern is that "leaf" methods should not be doing 
ThreadInVMFromNative so we shouldn't have to make any changes to the 
definition of JNI_LEAF because of this. :(

I think this use of JNI_LEAF needs to be re-examined, but I won't insist 
on that here or object to the proposed changes.

Thanks,
David
-----

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