平媒用稿，请勿转载

咳咳，本来应该直接突入下一章，突然想起来stackMap的一些小问题，在这里补充一下说明

遇到旧版的jar包怎么办？
当然旧版的jar包是是不可能给你stackMap的，甚至也不会给你内联finally中的代码块。这个时候，用proguard工具preverify一下，就有了。很多之前开发过j2me的同学可能对这个眼熟，对，本身stackMap就是从j2me里面拿过来的好用的东西。
遇到一些旧代码直接生成的字节码怎么办？
很多~~旧版的~~字节码生成工具生成的代码中，（包括但不限于旧版的asm ~~.js，啊不，没.js~~，甚至包括Harmony自带的Proxy实现），没有放进去stackMap（当然也不会内联jsr）。sun对这种情况的推荐是保留原来的复杂的逻辑，从0开始计算stackMap，不过实在是过于复杂。我个人虽然推荐抛弃掉这些时代的眼泪，不过Harmony已经被apache废弃了，指望他们更新是不可能了，而Harmony目前是我看到的唯一的可以让你随便折腾里面的代码还不用开源runtime库，所以只能忍痛考虑一下怎么办。不过幸好Harmony的Proxy实现生成的代码中一不包含跳转二不包含jsr，因此就这么着了。。。
都做到这个地步了为啥不JIT？
简单地说……我不会orz。复杂点说，首先，JIT这种东西需要动态生成可执行的代码，这部分代码在不同平台上是不一样的，而且动态生成的代码在iOS下根本无法执行（Android下倒是无所谓）所以干脆就不动这个念头了；其次，JIT并不单纯是一个一下子“叮”就能解决一切性能问题的简单方案，java自带的JIT之所以能跑到接近C语言一半的性能，主要是因为java在JIT的时候重新对字节码进行了优化，可以认为是基于profile用-O3甚至是-lto进行了全面的重编译，一般的JIT也是作不到的

那么言归正传，在应用stackMap，废弃掉typeStack之后，Linpack测试立马从25flops涨到47flops，涨幅接近60%。那么还能不能更快？

这个还得且听下回分解～

高可移植解释型虚拟机优化专场·第一章·补February 24, 2015

目录