Field on top of
java.lang.invoke method handles. Making method handles the underlying
mechanism for reflection will reduce the maintenance and development cost of
It is not a goal to make any change to the
java.lang.reflect API. This is
solely an implementation change.
Core reflection has two internal mechanisms for invoking methods and constructors. For fast startup, it uses native methods in the HotSpot VM for the first few invocations of a specific reflective method or constructor object. For better peak performance, after a number of invocations it generates bytecode for the reflective operation and uses that in subsequent invocations.
For field access, core reflection uses the internal
java.lang.invoke method-handle API introduced in Java 7, there
are altogether three different internal mechanisms for reflective operations:
VM native methods,
Dynamically generated bytecode stubs for
Constructor::newInstance, along with
Unsafefield access for
When we update
java.lang.invoke to support new
language features, such as those envisioned in Project Valhalla, we
must modify all three code paths, which is costly. In addition, the current
implementation relies on special treatment by the VM of the generated bytecode,
which is wrapped in subclasses of
<code class="prettyprint" data-shared-secret="1656154985197-0.16423641918685672">jdk.internal.reflect.MagicAccessorImpl</code>:
Accessibility is relaxed so that these classes can access inaccessible fields and methods of other classes,
Verification is disabled to work around JLS §6.6.2 in order to support reflection on
A non-well-behaved class loader is used to work around some security and compatibility issues.
java.lang.reflect on top of method handles as the common
underlying reflective mechanism of the platform by replacing the
bytecode-generating implementations of
The new implementation performs direct invocations of the method handles for specific reflective objects. We use the VM's native reflection mechanism only during early VM startup, before the method-handle mechanism is initialized. That happens soon after <code class="prettyprint" data-shared-secret="1656154985197-0.16423641918685672">System::initPhase1</code> and before <code class="prettyprint" data-shared-secret="1656154985197-0.16423641918685672">System::initPhase2</code>, after which we switch to using method handles exclusively. This benefits Project Loom by reducing the use of native stack frames.
For optimal performance,
should be held in
static final fields so that they can be
constant-folded by the JIT. When that is done, microbenchmarks show that
the performance of the new implementation is significantly faster than
the old implementation, by 43–57%.
Field instances are held in
non-constant fields (e.g., in a non-
final field or an array element),
microbenchmarks show some performance degradation. The performance of
field accesses is significantly slower than the old implementation, by
Field instances cannot be constant-folded.
This degradation may, however, not have much effect on the performance of real-world applications. We ran several serialization and deserialization benchmarks using real-world libraries and found no degradation in
- A custom JSON serialization and deserialization benchmark using Jackson,
- An XStream converter type benchmark, or
- A Kryo field serializer benchmark.
We will continue to explore opportunities to improve performance, for
example by refining the bytecode shapes for field access to enable
VarHandles to be reliably optimized by the
JIT regardless of whether the receiver is constant.
The new implementation will reduce the cost of upgrading reflection
support for new language features and, further, will allow us to simplify
the HotSpot VM by removing the special treatment of
Alternative 1: Do nothing
Retain the existing core reflection implementation to avoid any compatibility risk. The dynamic bytecode generated for core reflection would remain at class file version 49, and the VM would continue to treat such bytecode specially.
We reject this alternative because
The cost of updating
java.lang.invoketo support Project Valhalla's primitive classes and generic specialization would be high,
Additional special rules in the VM would likely be needed to support new language features within the limitation of the old class-file format, and
Project Loom would need to find a way to handle the introduction of native stack frames by core reflection.
Alternative 2: Upgrade to a new bytecode library
Replace the bytecode writer used by core reflection to use a new bytecode library that evolves together with the class-file format, but otherwise retain the existing core reflection implementation and continue to treat dynamically-generated reflection bytecode specially.
This alternative has lower compatibility risk than what we propose above, but it is still a sizeable amount of work and it still has the first and last disadvantages of the first alternative.
Comprehensive testing will ensure that the implementation is robust and compatible with existing behavior. Performance testing will ensure that there are no unexpected significant performance regressions compared to the current implementation. We will encourage developers using early-access builds to test as many libraries and frameworks as possible in order to help us identify any behavior or performance regressions.Baseline
Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.constructorConst avgt 10 68.049 ± 0.872 ns/op ReflectionSpeedBenchmark.constructorPoly avgt 10 94.132 ± 1.805 ns/op ReflectionSpeedBenchmark.constructorVar avgt 10 64.543 ± 0.799 ns/op ReflectionSpeedBenchmark.instanceFieldConst avgt 10 35.361 ± 0.492 ns/op ReflectionSpeedBenchmark.instanceFieldPoly avgt 10 67.089 ± 3.288 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 35.745 ± 0.554 ns/op ReflectionSpeedBenchmark.instanceMethodConst avgt 10 77.925 ± 2.026 ns/op ReflectionSpeedBenchmark.instanceMethodPoly avgt 10 96.094 ± 2.269 ns/op ReflectionSpeedBenchmark.instanceMethodVar avgt 10 80.002 ± 4.267 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 33.442 ± 2.659 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 51.918 ± 1.522 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 33.967 ± 0.451 ns/op ReflectionSpeedBenchmark.staticMethodConst avgt 10 75.380 ± 1.660 ns/op ReflectionSpeedBenchmark.staticMethodPoly avgt 10 93.553 ± 1.037 ns/op ReflectionSpeedBenchmark.staticMethodVar avgt 10 76.728 ± 1.614 ns/op
Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.constructorConst avgt 10 32.392 ± 0.473 ns/op ReflectionSpeedBenchmark.constructorPoly avgt 10 113.947 ± 1.205 ns/op ReflectionSpeedBenchmark.constructorVar avgt 10 76.885 ± 1.128 ns/op ReflectionSpeedBenchmark.instanceFieldConst avgt 10 18.569 ± 0.161 ns/op ReflectionSpeedBenchmark.instanceFieldPoly avgt 10 98.671 ± 2.015 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 54.193 ± 3.510 ns/op ReflectionSpeedBenchmark.instanceMethodConst avgt 10 33.421 ± 0.406 ns/op ReflectionSpeedBenchmark.instanceMethodPoly avgt 10 109.129 ± 1.959 ns/op ReflectionSpeedBenchmark.instanceMethodVar avgt 10 90.420 ± 2.187 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 19.080 ± 0.179 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 92.130 ± 2.729 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 53.899 ± 1.051 ns/op ReflectionSpeedBenchmark.staticMethodConst avgt 10 35.907 ± 0.456 ns/op ReflectionSpeedBenchmark.staticMethodPoly avgt 10 102.895 ± 1.604 ns/op ReflectionSpeedBenchmark.staticMethodVar avgt 10 82.123 ± 0.629 ns/op
Risks and Assumptions
Code that depends upon highly implementation-specific and undocumented aspects
of the existing implementation may be impacted. To mitigate this compatibility
risk, as a workaround you can enable the old implementation via
Code that inspects the internal generated reflection classes (i.e., subclasses of
MagicAccessorImpl) will no longer work and must be updated.
Method-handle invocation may consume more resources than the old core reflection implementation. Such invocation involves calling multiple Java methods to ensure that the declaring class of a member is initialized prior to access, and thus may require more stack space for the necessary execution frames. This may result in a
StackOverflowErroror, if a
StackOverflowErroris thrown while initializing a class, then a
We will remove the old core reflection implementation in a future release. The
-Djdk.reflect.useDirectMethodHandle=falseworkaround will stop working at that point.