RFR: 8268406: Deallocate jmethodID native memory [v7]

[David Holmes]

On Fri, 20 Jun 2025 20:47:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I think this should prevent this race but I'd have to think about it some more.

Aside from the fact the `checked` method is not used much, the problem is that if the caller does not have something keeping the class alive, then the resolution of the jMethodID can succeed and we will proceed with trying to call the method. In the meantime the fact the class is unreferenced could be noticed and the class then unloaded. Now that can only happen at safepoints, so it then depends on the details of the code that tries to invoke the method e.g. in jni.cpp

static void jni_invoke_static(JNIEnv *env, JavaValue* result, jobject receiver, JNICallType call_type, jmethodID method_id, JNI_ArgumentPusher *args, TRAPS) {
  methodHandle method(THREAD, Method::resolve_jmethod_id(method_id));

  // Create object to hold arguments for the JavaCall, and associate it with
  // the jni parser
  ResourceMark rm(THREAD);
  int number_of_parameters = method->size_of_parameters();
  JavaCallArguments java_args(number_of_parameters);

  assert(method->is_static(), "method should be static");

  // Fill out JavaCallArguments object
  args->push_arguments_on(&java_args);
  // Initialize result type
  result->set_type(args->return_type());

  // Invoke the method. Result is returned as oop.
  JavaCalls::call(result, method, &java_args, CHECK);

Can we hit safepoint checks anywhere on the path to the actual invocation of the method? If not, what is guaranteeing that?

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2994989682