RFR: 8332547: Unloaded signature classes in DirectMethodHandles

[Chen Liang]

On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov <vlivanov at 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

src/java.base/share/classes/sun/invoke/util/VerifyAccess.java line 291:

> 289:         // guarantees that classes with names beginning "java." cannot be aliased,
> 290:         // because class loaders cannot load them directly. However, it is beneficial
> 291:         // for JIT-compilers to ensure all signature classes are loaded.

Since we anticipate this method to perform side effects, can we rename all of these non-pure `isTypeVisible` to `seeType`/`accessType` to indicate this desired side effect?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19319#discussion_r1607426203