Java理论与实践: 动态编译与性能测量 - 编程入门网
合理的推断。
而在另一方面,HotSpot JIT 在程序运行时会持续地把 Java 字节码重新编 译成机器码,而重新编译触发的次数无法预期,触发重新编译的依据是性能分析 数据积累到一定数量、装入新类,或者执行到的代码路径的类已经装入,但是还 没有执行过。持续的重新编译情况下的时间测量会非常混乱、让人误解,而且要 想获得有用的性能数据,通常必须让 Java 代码运行相当长的时间(我曾经看到 过一些怪事,在程序启动运行之后要加速几个小时甚至数天),才能获得有用的 性能数据。 清除死代码 编写好评测的一个挑战就是,优化编译器要擅长找出死代码 —— 对于程序 执行的输出没有作用的代码。但是评测程序一般不产生任何输出,这就意味着有 一些,或者全部代码都有可能被优化掉,而毫无知觉,这时您实际测量的执行要 少于您设想的数量。具体来说,许多微评测在用 -server 方式运行时,要比用 -client 方式运行时好得多,这不是因为服务器编译器更快(虽然服务器编译器 一般更快),而是因为服务器编译器更擅长优化掉死代码。不幸的是,能够让您 的评测工作非常短(可能会把评测完全优化掉)的死代码优化,在处理实际做些 工作的代码时,做得就不会那么好了。 Java理论与实践: 动态编译与性能测量(3)时间:2010-12-21 IBM Brian Goetz奇怪的结果 清单 1 的评测包含一个什么也不做的代码块,它是从一个测试并发线程性能 的评测中摘出来的,但是它实际测量的根本不是要评测的东西。 清单 1. 被意料之外的死代码弄乱的评测
表面上看, doSomeStuff() 方法可以给线程分点事做,所以我们能够从 StupidThreadBenchmark 的运行时间推导出多线程调度开支的一些情况。但是, 因为 uselessSum 从没被用过,所以编译器能够判断出 doSomeStuff 中的全部 代码是死的,然后把它们全部优化掉。一旦循环中的代码消失,循环也就消失了 ,只留下一个空空如也的 doSomeStuff。表 1 显示了使用客户机和服务器方式 执行 StupidThreadBenchmark 的性能。两个 JVM 运行大量线程的时候,都表现 出差不多是线性的运行时间,这个结果很容易被误解为服务器 JVM 比客户机 JVM 快 40 倍。而实际上,是服务器编译器做了更多优化,发现整个 doSomeStuff 是死代码。虽然确实有许多程序在服务器 JVM 上会提速,但是您 在这里看到的提速仅仅代表一个写得糟糕的评测,而不能成为服务器 JVM 性能 的证明。但是如果您没有细看,就很容易会把两者混淆。 表 1. 在 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |