RFR: 8332547: Unloaded signature classes in DirectMethodHandles

Vladimir Ivanov vlivanov at openjdk.org
Mon May 20 22:00:26 UTC 2024


JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 

There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.

Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 

In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  

Testing: hs-tier1 - hs-tier4

-------------

Commit messages:
 - Fix
 - Test

Changes: https://git.openjdk.org/jdk/pull/19319/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19319&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332547
  Stats: 74 lines in 2 files changed: 68 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19319/head:pull/19319

PR: https://git.openjdk.org/jdk/pull/19319


More information about the hotspot-compiler-dev mailing list