RFR: 8332547: Unloaded signature classes in DirectMethodHandles [v2]
    Chen Liang 
    liach at openjdk.org
       
    Mon Jun  3 22:33:49 UTC 2024
    
    
  
On Mon, 3 Jun 2024 19:36:58 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
>
> 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
    
    
More information about the core-libs-dev
mailing list