Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov 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 > > Vladimir Ivanov has updated the pull request incrementally with one > additional commit since the last revision: > > Renaming: isTypeVisible -> ensureTypeVisible Thanks for the reviews, Jorn and Chen. - PR Comment: https://git.openjdk.org/jdk/pull/19319#issuecomment-2146542294
Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov 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 > > Vladimir Ivanov has updated the pull request incrementally with one > additional commit since the last revision: > > Renaming: isTypeVisible -> ensureTypeVisible Marked as reviewed by liach (Author). - PR Review: https://git.openjdk.org/jdk/pull/19319#pullrequestreview-2094960904
Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov 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 > > Vladimir Ivanov has updated the pull request incrementally with one > additional commit since the last revision: > > Renaming: isTypeVisible -> ensureTypeVisible Thanks - Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19319#pullrequestreview-2094825208
Re: RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]
> 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 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Renaming: isTypeVisible -> ensureTypeVisible - Changes: - all: https://git.openjdk.org/jdk/pull/19319/files - new: https://git.openjdk.org/jdk/pull/19319/files/805d42fc..058cdba3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19319&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19319&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 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
