RFR: 8284877: Check type compatibility before looking up method from receiver's vtable [v2]

[Yi Yang]

On Mon, 19 Jun 2023 02:41:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> validate_call
>> 
>> This check is exercised when jni_CallStaticVoidMethod is called, while aforementioned case is that JNI wrongly constructs an object and does a normal virtual call and gets correct result.
>
> @y1yang0  as far as I can see it is already being called via the following macro/wrapper:
> 
> #define WRAPPER_CallMethod(ResultType, Result) \
> JNI_ENTRY_CHECKED(ResultType,  \
>   checked_jni_Call##Result##Method(JNIEnv *env, \
>                                    jobject obj, \
>                                    jmethodID methodID, \
>                                    ...)) \
>     functionEnter(thr); \
>     va_list args; \
>     IN_VM( \
>       jniCheck::validate_call(thr, nullptr, methodID, obj); \
>     ) \
>     va_start(args,methodID); \
>     ResultType result =UNCHECKED()->Call##Result##MethodV(env, obj, methodID, \
>                                                           args); \
>     va_end(args); \
>     thr->set_pending_jni_exception_check("Call"#Result"Method"); \
>     functionExit(thr); \
>     return result; \
> JNI_END \

@dholmes-ora 
> as far as I can see it is already being called via the following macro/wrapper:
I mean, users constructs object by JNI and crash when interpreting `odpsFileStatus.getPath().toString()`, `odpsFileStatus.getPath().toString()` is not a JNI call.

The difference between this JNI example and the previous Unsafe example is that in the latter case, users knew that there might be errors in their code because the JVM crashed, while in the former case, users didn't know their code was erroneous and the JVM also didn't throw any exceptions (prior to this patch).


@dcubed-ojdk 
> If the VM changes are backed out, what does the new test do?
If revert this patch, attached test causes JVM crash somewhat randomly.

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

PR Comment: https://git.openjdk.org/jdk/pull/8241#issuecomment-1617109332