Fre*_*ind 6 java optimization jvm-hotspot
当我阅读"Scala in depth"一书时,它提到HotSpot编译器有几个重要的功能,其中之一就是"动态去优化":
事实上,它能够确定优化是否不会提高性能并撤消优化,从而允许其他优化应用
似乎HotSpot会尝试各种"优化",并选择其中最好的一个.
但我不是很了解它.这里的"优化"是否全部由HotSpot提供?我的意思是程序员经常尝试用一些技巧来优化代码,HotSpot会处理它们吗?
HotSpot会尝试任何常见的"优化"吗?
Raf*_*ter 11
Oracle提供了JVM应用的这种性能技术的(相当简明的)摘要.它解释说:
去优化是将优化的堆栈帧更改为未优化的堆栈帧的过程.对于已编译的方法,它也是使用无效的乐观优化丢弃代码,并用更少优化,更健壮的代码替换它的过程.原则上可以对方法进行数十次去优化.
在本摘要中,去优化的原因如下:
- 编译器可能会删除一个未被删除的分支,并且如果它被采用则去优化.
- 同样,对于历史上从未失败的低级别安全检查.
- 如果调用站点或强制转换遇到意外类型,编译器将取消优化.
- 如果加载的类使早期的类层次结构分析无效,则任何线程中的任何受影响的方法激活都将被强制为安全点并进行去优化.
- 这种间接的去优化是由依赖系统调节的.如果编译器进行未经检查的假设,则必须注册可检查的依赖项.(例如,该类Foo没有子类,或者方法Foo.bar没有覆盖.)
就个人而言,我发现这篇关于微基准测试的博客文章非常易读,也涵盖了HotSpot VM上的优化和去优化主题.另外,我可以推荐阅读本演示文稿.
HotSpot的优化与开发人员在Java源代码级别上的优化不同,尽管其中一些具有相同的净效果.
这是JIT编译器库的一部分:
最有趣的部分是一些优化之间的协同作用,例如:
但是,你的引言是我所知道的错误.优化的代码不会进行任何自我分析,因为它会降低它的速度.去优化的唯一条件是违反乐观假设,在这些假设下代码是JIT编译的.示例:给定的方法调用站点只接收一种类型的对象,专门用于该对象(编译为单态调用站点),但稍后会出现不同的对象类型.现在优化的代码无法执行,必须进行去优化.
“编译器优化”是对代码的一种转换,试图使其在某种意义上变得更好——通常是减少执行时间。维基百科关于优化编译器的文章列出了所采取的常见优化;Hotspot JIT 编译器可能会完成所有这些工作,甚至更多。
因此,这本书意味着 Hotspot 会将其中一些技术应用到代码中,看看它是否改进了运行时间,如果没有,它将恢复它。
正如您所正确指出的,手动更改代码以使其更好的过程也称为“优化”或“手动优化”。编译器尝试应用尽可能多的优化,但仍然需要手动应用许多可能的修改。维基百科再次有一篇关于什么是程序优化的可靠文章。
归档时间: |
|
查看次数: |
2791 次 |
最近记录: |