问题描述
我最近一直在尝试了解JVM转义分析.根据这个不错的答案，我尝试了很多JVM选项的组合.我的问题是，这些选项值是否有硬性限制?类似于FreqInlineSize，MaxInlineLevel.当我将选项设置为一些荒谬的值时，JVM不会认真对待它，例如-XX:FreqInlineSize=65535会吗?实际上，我尝试过.但是jvm对此没有抱怨.所以我真的不知道.
I've been trying to understand JVM escape analyis recently. I tried a lot of combination of the JVM options according to this nice answer. My question is that is there any hard limit on thoses option values? Like FreqInlineSize, MaxInlineLevel. JVM wouldn't take it seriously when I set the options to some ridiculous value, like -XX:FreqInlineSize=65535 will it? Actually, I tried that. But jvm didn't complain about it. So I really cannot tell.
如果有一些硬性限制，那会是什么?在哪里可以找到描述此类内容的文档?
If there is some hard limit, what would that be? Where can I find the documents that describes such things?
我一直试图找到一种方法来强制将Protobuf消息和构建器对象分配在堆栈上而不是堆上.有时它可以工作.但是，当消息对象的字段数增加时，它将停止工作.我在互联网上搜索了很多内容，但由于对这一主题的了解有限，因此发现很少.那就是我为什么要问.
I've been trying to find a way to force my Protobuf message and builder objects to be allocated on stack instead of on heap. Sometimes it works. But when the number of fields of the message object grows, it stopped working. I searched a lot on the internet but with little findings due to my limited understanding on the subject. So That why I am asking.
JVM版本:Java HotSpot(TM)64位服务器VM(内部版本25.131-b11，混合模式)
JVM version:Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
推荐答案
- 您提到的选项控制内联，而不是转义分析.
- 这些值没有硬性限制，或更确切地说，限制是
INT_MAX. - 但是，实际上，内联和其他优化受到其他限制的约束，例如
NodeCountInliningCutoff(不可调整)，MaxNodeLimit，NodeLimitFudgeFactor等. - 除了在源代码.
- The options you mention control inlining, not the escape analysis.
- There is no hard limit one these values, or, more precisely, the limit is
INT_MAX. - In practice, however, inlining and other optimizations are bounded by other limits such as
NodeCountInliningCutoff(not tunable),MaxNodeLimit,NodeLimitFudgeFactoretc. - I doubt you'll find much documentation on these things other than in source code.
这篇关于JVM标志是否有硬性限制来控制转义分析?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！