Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8327624

Remove VM implementation that bypass verification for core reflection

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 24
    • 23
    • core-libs
    • None

      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.

            mchung Mandy Chung (Inactive)
            mchung Mandy Chung (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: