-
Enhancement
-
Resolution: Fixed
-
P4
-
23
-
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 (seeJDK-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.
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
- 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.
- blocks
-
JDK-8342561 Metaspace for generated reflection classes is no longer needed
-
- Resolved
-
- csr for
-
JDK-8342574 Remove VM implementation that bypass verification for core reflection
-
- Closed
-
- relates to
-
JDK-8315810 Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles
-
- Resolved
-
-
JDK-8266010 JEP 416: Reimplement Core Reflection with Method Handles
-
- Closed
-
- links to
-
Commit(master) openjdk/jdk/d6eddcda
-
Review(master) openjdk/jdk/21571
(1 links to)