【问题标题】:Is there any hard limit on the JVM flags to control escape analysis?JVM 标志是否有任何硬性限制来控制逃逸分析?
【发布时间】:2018-03-21 09:34:37
【问题描述】:

我最近一直在尝试了解 JVM 逃逸分析。我根据this nice answer尝试了很多JVM选项的组合。我的问题是,这些选项值是否有任何硬性限制?喜欢FreqInlineSizeMaxInlineLevel。当我将选项设置为一些荒谬的值时,JVM 不会认真对待它,比如-XX:FreqInlineSize=65535 会吗?事实上,我试过了。但是jvm并没有抱怨。所以我真的说不出来。

如果有一些硬性限制,那会是什么?我在哪里可以找到描述此类事情的文档?


我一直在尝试找到一种方法来强制将我的 Protobuf 消息和构建器对象分配到堆栈上而不是堆上。有时它会起作用。但是当消息对象的字段数量增加时,它就停止了工作。我在互联网上搜索了很多,但由于我对这个主题的了解有限,我几乎没有发现任何结果。所以这就是我问的原因。


JVM 版本: Java HotSpot(TM) 64 位服务器 VM(内部版本 25.131-b11,混合模式)

【问题讨论】:

    标签: java jvm escape-analysis


    【解决方案1】:
    • 您提到的选项控制内联,而不是转义分析。
    • 这些值没有硬性限制,或者更准确地说,限制是INT_MAX
    • 但实际上,内联和其他优化受到其他限制的限制,例如 NodeCountInliningCutoff(不可调整)、MaxNodeLimitNodeLimitFudgeFactor 等。
    • 我怀疑除了source code 之外,您还能找到更多关于这些内容的文档。

    【讨论】:

    • this answer 提到了内联和转义分析的关系。据我了解,之所以需要all its uses are inlined,是因为当非内联方法将对象作为参数时,如果所述对象被堆栈分配/标量替换,它必须知道不存在的对象地址。我相信it is never assigned to any static or object fields 或更准确地说,非转义对象字段的原因相同。不过,以上所有只是我的猜测。你能澄清我的疑问吗?
    猜你喜欢
    • 2019-01-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-01-03
    • 2015-06-10
    • 1970-01-01
    • 2021-06-22
    • 2015-02-27
    相关资源
    最近更新 更多