如果大多数方法在调用站点上都是死代码,那么Java可以内联一个大方法吗？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了如果大多数方法在调用站点上都是死代码,那么Java可以内联一个大方法吗？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1260字，纯文字阅读大概需要2分钟。

内容图文

我知道Java HotSpot用来确定某个方法是否值得内联的标准之一是该方法的大小.一方面,这似乎是明智的：如果方法很大,则内联会导致代码膨胀,并且该方法执行将花费很长时间,因此调用开销很小.这种逻辑的麻烦在于,在您决定内联后,可能会发现对于这个特定的调用站点,大多数方法都是无效代码.例如,该方法可能是一个巨大的switch语句,但是大多数调用站点都使用编译时常量来调用该方法,因此实际上：内联便宜(不需要整个方法主体；代码膨胀最少)并且有效(方法调用开销主导着实际完成的工作).

HotSpot是否具有任何机制来利用这种情况并无论如何都内联该方法,或者是否有一个限制,即使它具有最小的代码膨胀效果,它甚至拒绝考虑内联一个方法？

解决方法:

HotSpot JIT内联策略相当复杂.它涉及许多启发式方法,例如调用方方法大小,被调用方方法大小,IR节点计数,内联深度,调用计数,呼叫站点计数等.

有一些硬性限制阻止大型方法内联,包括：

> -XX：FreqInlineSize = 325-要内联的被调用方的最大大小(以字节码为单位)；
> -XX：InlineSmallCode = 2000-如果被调用者已经具有至少此大小的已编译代码(以字节为单位),则不要内联；
> -XX：NodeCountInliningCutoff = 18000-如果解析器生成此数量的IR节点,则停止内联；
> -XX：DesiredMethodLimit = 8000-内联后聚合方法的最大字节码大小.此参数在HotSpot的产品版本中不可调整,但是可以使用-XX：-ClipInlining关闭该限制.

还有其他限制,但是,正如您已经看到的,即使-XX：默认情况下启用了InXX,IncrementalInline也没有很大的机会进行内联.

内容总结

以上是互联网集市为您收集整理的如果大多数方法在调用站点上都是死代码,那么Java可以内联一个大方法吗？全部内容，希望文章能够帮你解决如果大多数方法在调用站点上都是死代码,那么Java可以内联一个大方法吗？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端