On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
> 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 This pull request has now been integrated. Changeset: 29e10e45 Author: Vladimir Ivanov <vliva...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/29e10e4582c1a844a6db4c42ba01bd1d6d4dfd52 Stats: 83 lines in 4 files changed: 68 ins; 0 del; 15 mod 8332547: Unloaded signature classes in DirectMethodHandles Reviewed-by: jvernee, liach ------------- PR: https://git.openjdk.org/jdk/pull/19319
