why the jdk native refactor get class from heap-CodePudding

I am reading the jdk 19(support the m1 chip when compile) source code, in the refactor source code in reflection.cpp, the function look like this:

oop Reflection::invoke_method(oop method_mirror, Handle receiver, objArrayHandle args, TRAPS) {
  oop mirror             = java_lang_reflect_Method::clazz(method_mirror);
  int slot               = java_lang_reflect_Method::slot(method_mirror);
  bool override          = java_lang_reflect_Method::override(method_mirror) != 0;
}

when I tracing this clazz function java_lang_reflect_Method::clazz:

oop java_lang_reflect_Method::clazz(oop reflect) {
  return reflect->obj_field(_clazz_offset);
}

the obj_field function get the oop data from heap. This makes me a little confusing, the heap store the all object instance, why the reflection get data from heap? I think it will get the metadata from Method Area because in there store the class metadata, using the metadata, could construct the class info. the obj_field look like this:

inline oop  oopDesc::obj_field(int offset) const                    { return HeapAccess<>::oop_load_at(as_oop(), offset);  }

CodePudding user response：

This reads the clazz field of a java.lang.reflect.Method object.

java.lang.reflect.Method is a regular Java class (with some support from native helpers). Why do you expect it not to be stored on the heap?

Note that java.lang.reflect.Method is not the same as a hotspot-internal C class Method.

The class Method is an implementation detail of the hotspot JVM engine and instances of this internal C class are never stored on the heap.