Java中的转义分析
据我所知,JVM 使用转义分析来进行某些性能优化比如锁粗化和锁省略。 我感兴趣的是 JVM 是否有可能决定可以使用逃逸分析在堆栈上分配任何特定对象。
一些资源让我认为我是对的。 是否有 JVM 能够真正做到这一点?
As far as I know the JVM uses escape analysis for some performance optimisations like lock coarsening and lock elision.
I'm interested if there is a possibility for the JVM to decide that any particular object can be allocated on stack using escape analysis.
Some resources make me think that I am right. Is there JVMs that actually do it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
使用此版本的 java -XX:+DoEscapeAnalysis 可以大大减少 gc 活动,并且执行速度提高 14 倍。
没有逃逸分析,
有逃逸分析,
有逃逸分析执行时间显着减少。 为此,循环更改为 10e9 次迭代,
没有逃逸分析,
有逃逸分析,
因此,在有逃逸分析的情况下,示例的运行速度比非逃逸分析的运行速度快约 14 倍。
With this version of java -XX:+DoEscapeAnalysis results in far less gc activity and 14x faster execution.
Without escape analysis,
With escape analysis,
The execution time reduces significantly with escape analysis. For this the loop was changed to 10e9 iterations,
Without escape analysis,
With escape analysis,
So with escape analysis the example ran about 14x faster than the non-escape analysis run.
我不认为它会对堆栈分配进行转义分析。 示例:
使用
-server -verbose:gc -XX+DoEscapeAnalysis
:据称 JDK 7 支持堆栈分配。
I don't think it does escape analysis for stack allocation. example:
with
-server -verbose:gc -XX+DoEscapeAnalysis
:Allegedly JDK 7 supports stack allocation.
越狱分析确实不错,但这并不是完全获得越狱卡。 如果对象内部有一个动态大小的集合,则逃逸分析不会从堆切换到堆栈。 例如:
即使这个对象是在方法中创建的,并且从语法的角度来看绝对不会转义,编译器也不会将其标记为转义。 我怀疑是因为从纯粹的语法角度来看, longList 的大小并没有真正限制,它可能会破坏你的堆栈。 因此我认为这个案子需要通过。 我对此进行了实验,其中 longList 为空,但它仍然在一个简单的微基准测试中引起了集合。
Escape analysis is really nice, but it is not a complete get of jail free card. if you have a dynamically sized collection inside of an object, the escape analysis will NOT switch from heap to stack. For example:
Even if this object is created in a method and absolutely does NOT escape from a syntactic point of view, the compiler will not mark this for escape. I suspect because that longList is not really bounded in size from a pure syntactic perspective and it could blow your stack potentially. Thus I believe it takes a pass on this case. I experimented with this where the longList was empty and still it caused collections in a simple micro benchmark.