JEP 416 and JDK-8315810 reimplemented core reflection and sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles.  The old core reflection implementation has been removed in JDK 22.  

VM special casing added for the old core reflection and serialization support can be removed along with the removal of sun.reflect.ReflectionFactory::newConstructorForSerialization method in a future release.

A summary of the VM changes to be removed include the following:

- VM skips verification for these dynamic bytecode stubs for reflection
  (`jdk.internal.reflect.MagicAccessorImpl` classes) because
  the dynamic bytecode stub `C` in calling `Object.clone` reflectively
  would fail verification as `C` is a subclass of `Object`
  and `C` is not allowed to call `Object::clone` per JLS section 6.6.2
  (see JDK-4486457)

- Each dynamic bytecode stub class is defined by a new class loader
  (an instance of `jdk.internal.reflect.DelegatingClassLoader`) whose
  parent class loader is the defining loader of the target class
  such that these classes can be be unloaded early even if
  the target class and its defining loader is still reachable.
  However, the VM has the following special handling of `DelegatingClassLoader`:
    - The dynamic bytecode stubs exposed bugs in custom class loader
      implementations that native reflection implementation never runs into.
      For compatibility, VM has to workaround for the ill-behaved custom class loaders
      and bypass the normal class loader delegation implementation.
      Instead it magically delegates class loading to to its parent loader
      directly in the VM (see JDK-4474172 and JDK-6790209 for details)
    - Metaspace is allocated for class loaders which generally loads
      more than one class but each `DelegatingClassLoader` instance
      only loads one single class. To reduce the amount of unused
      space reserved, VM has to create a custom-sized metaspace of
      `ReflectionMetaspaceType` for these `DelegatingClassLoader` loaders.
    - jcmd has to specially inspect these dynamic bytecode stubs
      to help determine the specific metaspace usage for core reflection.
    - Deserialization relies on VM support (`JVM_LatestUserDefinedLoader`)
      to look up the latest user-defined loader. `JVM_LatestUserDefinedLoader`
      has to specially filter these dynamic bytecode stubs since
      they are defined by non built-in class loaders.