JEP 416: Reimplement Core Reflection with Method HandlesJEP 416: Reimplement Core Reflection with Method HandlesOwnerMandy ChungTypeFeatureScopeJDKStatusClosed / DeliveredRelease18Componentcore-libs / java.lang:reflectDiscussioncore dash libs dash dev at openjdk dot java dot netEffortMDurationMReviewed byAlan Bateman, John RoseEndorsed byJohn RoseCreated2021/04/26 22:41Updated2024/03/07 18:49Issue8266010Summary
Reimplement java.lang.reflect.Method, Constructor, and 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
both the java.lang.reflect and java.lang.invoke APIs.
Non-Goals
It is not a goal to make any change to the java.lang.reflect API.  This is
solely an implementation change.
Motivation
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 sun.misc.Unsafe API.
With the 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 Method::invoke and
Constructor::newInstance, along with Unsafe field access for
Field::get and set, and


Method handles.


When we update java.lang.reflect and 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
jdk.internal.reflect.MagicAccessorImpl:


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 Object::clone, and


A non-well-behaved class loader is used to work around some security and
compatibility issues.


Description
Reimplement java.lang.reflect on top of method handles as the common
underlying reflective mechanism of the platform by replacing the
bytecode-generating implementations of Method::invoke,
Constructor::newInstance, Field::get, and Field::set.
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
System::initPhase1 and before
System::initPhase2, after which we switch to using method
handles exclusively.  This benefits Project Loom by reducing the use of
native stack frames.
For optimal performance, Method, Constructor, and Field instances
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%.
When Method, Constructor, and 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
51–77%, when 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
concrete MethodHandles and 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 MagicAccessorImpl
subclasses.
Alternatives
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.reflect and java.lang.invoke to 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.
Testing
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
New implementation
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
-Djdk.reflect.useDirectMethodHandle=false.


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 StackOverflowError or, if a StackOverflowError
is thrown while initializing a class, then a NoClassDefFoundError.


We will remove the old core reflection implementation in a future release.
The -Djdk.reflect.useDirectMethodHandle=false workaround will stop working at that point.


InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
