该文章转载自:http://rdc.taobao.com/team/jm/archives/552
你写过超过2500行的方法么?通常来说,这么大的方法并不多见,一般都是使用机器辅助生成的为主,这种情况在模板编译或其它语言的自动转换中比较常见。例如,对一个复杂的JSP页面,机器有可能会为它生成一个复杂的servlet方法去实现。
然而在Hotspot上运行这种大方法,很可能会有性能问题。例如,把文章所附DEMO的play()方法的内容分别重复拷贝1、2、4、8、16、32次并依次运行,在我的机器(Hotspot_1.6u22/Windows)上得到的play()的执行消耗时间分别是28.43、54.72、106.28、214.41、419.30、1476.40毫秒/万次。在重复拷贝1~16次时,随着代码量增加,方法执行所消耗的时间也对应成倍增加。当重复拷贝32次时,方法却多消耗了80%的时间。如果把这个play()方法拆分成play1()和play2(),让它们的方法体都是16次的重复拷贝,play1()最后再调用play2(),那么,play1()+play2()的执行消耗时间是857.75毫秒/万次,恰好是之前重复拷贝16次所消耗的时间的两倍。为什么同样功能的一段代码放在一个方法中执行会变慢,拆分成两个方法就变快?
大家知道,JVM一开始是以解释方式执行字节码的。当这段代码被执行的次数足够多以后,它会被动态优化并编译成机器码执行,执行速度会大大加快,这就是所谓的JIT编译。DEMO的play()方法在被统计消耗时间之前,已经预热执行了2000次,满足ClientVM的方法JIT编译阈值CompileThreshold=1500次的要求,那么,它是不是真的被JIT编译了呢?我们可以增加VM参数”-XX:+PrintCompilation”调查一下。在+PrintCompilation打开以后,列出了JVM在运行时进行过JIT编译的方法。下面是经过32次重复拷贝的play()方法的JIT编译记录(只列出需要关心的部分):
34 HugeMethodDemo::buildTheWorld (184 bytes)
39 HugeMethodDemo::run (59 bytes)
而分成两部分的play1()+plaay2()的JIT编译记录则为:
18 HugeMethodDemo::play1 (4999 bytes)
19 HugeMethodDemo::play2 (4993 bytes)
36 HugeMethodDemo::buildTheWorld (184 bytes)
41 HugeMethodDemo::run (59 bytes)
显然,经过重复拷贝32次的play()方法没有经过JIT编译,始终采用解释方式执行,而分拆开的play1()+play2()经过JIT编译,所以难怪play()要慢80%。
为什么play()方法不受JVM青睐呢,是太长了么?这只能到Hotspot源码中去翻答案了。在compilationPolicy.cpp中有写道:
// Returns true if m is allowed to be compiled
bool CompilationPolicy::canBeCompiled(methodHandle m) {
if (m->is_abstract()) return false;
if (DontCompileHugeMethods && m->code_size() > HugeMethodLimit) return false;
// Math intrinsics should never be compiled as this can lead to
// monotonicity problems because the interpreter will prefer the
// compiled code to the intrinsic version. This can't happen in
// production because the invocation counter can't be incremented
// but we shouldn't expose the system to this problem in testing
// modes.
if (!AbstractInterpreter::can_be_compiled(m)) {
return false;
}
return !m->is_not_compilable();
}
当DontCompileHugeMethods=true且代码长度大于HugeMethodLimit时,方法不会被编译。DontCompileHugeMethods与HugeMethodLimit的值在globals.hpp中定义:
product(bool, DontCompileHugeMethods, true,
"don't compile methods > HugeMethodLimit")
develop(intx, HugeMethodLimit, 8000,
"don't compile methods larger than this if +DontCompileHugeMethods")
上面两个参数说明了Hotspot对字节码超过8000字节的大方法有JIT编译限制,这就是play()杯具的原因。由于使用的是product mode的JRE,我们只能尝试关闭DontCompileHugeMethods,即增加VM参数”-XX:-DontCompileHugeMethods”来强迫JVM编译play()。再次对play()进行测试,耗时855毫秒/万次,性能终于上来了,输出的JIT编译记录也增加了一行:
16 HugeMethodDemo::play (9985 bytes)
使用”-XX:-DontCompileHugeMethods”解除大方法的编译限制,一个比较明显的缺点是JVM会尝试编译所遇到的所有大方法,者会使JIT编译任务负担更重,而且需要占用更多的Code Cache区域去保存编译后的代码。但是优点是编译后可以让大方法的执行速度变快,且可能提高GC速度。运行时Code Cache的使用量可以通过JMX或者JConsole获得,Code Cache的大小在globals.hpp中定义:
define_pd_global(intx, ReservedCodeCacheSize, 48*M);
product_pd(uintx, InitialCodeCacheSize, "Initial code cache size (in bytes)")
product_pd(uintx, ReservedCodeCacheSize, "Reserved code cache size (in bytes) - maximum code cache size")
product(uintx, CodeCacheMinimumFreeSpace, 500*K, "When less than X space left, we stop compiling.")
一旦Code Cache满了,HotSpot会停止所有后续的编译任务,虽然已编译的代码不受影响,但是后面的所有方法都会强制停留在纯解释模式。因此,如非必要,应该尽量避免生成大方法;如果解除了大方法的编译限制,则要留意配置Code Cache区的大小,准备更多空间存放编译后的代码。
最后附上DEMO代码:
import java.io.StringWriter;
|
import java.util.HashMap;
|
public class HugeMethodDemo {
|
public static void main(String[] args) throws Exception {
|
HugeMethodDemo demo = new HugeMethodDemo();
|
double total = demo.run(loop);
|
double avg = total / loop / 1e6 * 1e4;
|
System.out.println(String.format(
|
"Loop=%d次, " + "avg=%.2f毫秒/万次" , loop, avg));
|
private long run( int loop) throws Exception {
|
for ( int i = 0 ; i < loop; i++) {
|
Map theWorld = buildTheWorld();
|
StringWriter console = new StringWriter();
|
long start = System.nanoTime();
|
long end = System.nanoTime();
|
private Map buildTheWorld() {
|
Map context = new HashMap();
|
context.put( "name" , "D&D" );
|
context.put( "version" , "1.0" );
|
Map game = new HashMap();
|
context.put( "game" , game);
|
Map player = new HashMap();
|
game.put( "player" , player);
|
player.put( "level" , "26" );
|
player.put( "name" , "jifeng" );
|
player.put( "job" , "paladin" );
|
player.put( "address" , "heaven" );
|
player.put( "weapon" , "sword" );
|
String[] bag = new String[] { "world_map" , "dagger" ,
|
"magic_1" , "potion_1" , "postion_2" , "key" };
|
private void play(Map theWorld, Writer console) throws Exception {
|
String name = String.valueOf(theWorld.get( "name" ));
|
String version = String.valueOf(theWorld.get( "version" ));
|
console.append( "Game " ).append(name).append( " (v" ).append(version).append( ")\n" );
|
Map game = (Map) theWorld.get( "game" );
|
Map player = (Map) game.get( "player" );
|
String level = String.valueOf(player.get( "level" ));
|
String job = String.valueOf(player.get( "job" ));
|
String address = String.valueOf(player.get( "address" ));
|
String weapon = String.valueOf(player.get( "weapon" ));
|
String hp = String.valueOf(player.get( "hp" ));
|
console.append( " You are a " ).append(level).append( " level " ).append(job)
|
.append( " from " ).append(address).append( ". \n" );
|
console.append( " Currently you have a " ).append(weapon).append( " in hand, " )
|
.append( "your hp: " ).append(hp).append( ". \n" );
|
console.append( " Here are items in your bag: \n" );
|
for (String item : (String[]) player.get( "bag" )) {
|
console.append( " * " ).append(item).append( "\n" );
|
console.append( "\tPlayer not login.\n" );
|
console.append( "\tGame not start yet.\n" );
|
[/java]
分享到:
相关推荐
再次对play()进行测试,耗时855毫秒/万次,性能终于上来了,输出的JIT编译记录也增加了一行: 16 HugeM
流程图与控制流图课堂小记.流程图与控制流图课堂小记.流程图与控制流图课堂小记.流程图与控制流图课堂小记.流程图与控制流图课堂小记.流程图与控制流图课堂小记.流程图与控制流图课堂小记.流程图与控制流图课堂小记....
对于配置过程其实比较简单只是纠结于在win32环境下apache 模块 mod_fcgid由于管道问题无法达成,而mod_fastcgi模块则可以达成
vuex使用方法,小记总结
互联网的快速发展,交互设计少了些可以借鉴的方法。交互设计这个行业似乎只能靠前人经验、自身灵感、悟性体会,江湖中野蛮发展着。简直就是武林中的内功了得。JJg在《用户体验要素》中,将交互设计设置在结构层。一...
【咬人草小记,阅读附答案】 咬人草小记阅读答案.docx
银行X银行营销服务系统性能测试小记[3]软件测试9、经验在本次性能测试的过程中,我们遇到一些问题,通过解决这些问题,从中获得了一些经验。现总结如下:在我们对系统进行测试的过程中,某些操作是相关联的。例如...
在偶然的机会听到了KDB,然后带着好奇和新鲜感体验了一把这个传说中和Oracle 相似度达到99%的数据库。 其中一部分的驱动力... 乍一看Oracle这边的人很占便宜,至少调优的基准和方式方法感觉都是熟悉的,不用过多的
环境: Linux s12084 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 i686 i686 i386 GNU/Linux gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3) boost 1.37.0 ... 全部编译是很痛苦的过程
关于开发过程中注意点的小记关于开发过程中注意点的小记关于开发过程中注意点的小记关于开发过程中注意点的小记关于开发过程中注意点的小记关于开发过程中注意点的小记
银行X银行营销服务系统性能测试小记[2]软件测试4、测试数据针对以上设计的测试用例,需要准备大量的业务数据。本次性能测试的环境即系统上线后真实运行的环境,所有的业务数据均来自X银行的真实核心系统(通过ETL转换...
阿里大数据分析平台使用小记,用于天池大数据竞赛平台,一些使用经验,不是完整的开发使用教程,仅供参考。具体的使用细节还得参考官网说明。
TCP-IP小记
严格来说,不能算是真正的scrum实践,但实践敏捷的过程本身也是一种“敏捷方法”,所以就算是“敏捷实践之敏捷开发方法-scrum过程”吧。 1.Scrum团队(5-7个人的小项目组)。 2.Backlog:急待完成的一系列任务,...
很全面的,很实用的,看完提高不少,不管新手老手,都绝对有用
银行X银行营销服务系统性能测试小记[1]软件测试1、背景本次性能测试的系统是X银行营销服务系统总行版,该系统使用的数据库服务器、应用服务器均布署在总行机房,各地分行通过WEB方式登录访问本系统。系统上线后的总...
随笔小记.doc