当ParparVM在基准测试中比预热后的Java 25慢4.21倍时,开发团队做了一个“不太公平”的决定——他们把桌子往自己这边倾斜,手工优化C代码,一门心思要和HotSpot掰手腕。结果出人意料:经过一系列激进改造,这套AOT虚拟机在10个基准测试里把几何平均性能拉到了1.00倍,与HotSpot完全打平,其中6个测试甚至跑出了更低的开销。整个过程中,团队没有在测试里作弊——每一次优化都用二进制完全一致校验和与HotSpot互锁,只要校验和不匹配,测试框架就拒绝给出比值。
ParparVM是开源跨平台框架Codename One的一部分,能够把Java字节码预编译为C,再交给平台原生工具链生成iOS、Android、桌面端和Web应用的可执行文件。它的原始设计讲究的是简单可靠、启动快、内存消耗低和原生调用流畅,吞吐量从来不是首要目标。在客户端场景里,渲染和I/O消耗了90%的时间,这些路径在Codename One中本来就是各个平台上手工打磨好的原生代码,所以团队很少把VM自身的吞吐量当作问题。直到最近一次性能“清账”,才决定系统性地改写代码生成、内存分配和垃圾回收。
这一次优化几乎把整个执行管线翻了一遍。新的基于页面的堆结构取代了原有的分配器,让对象创建和回收的流水线更适合CPU的缓存层次;同时引入了一套被团队称为“穷人版Project Valhalla”的机制,在不需要完整JVM改动的前提下,逼出了类似扁平化对象的内存效率。最关键的改动发生在代码生成环节:重新设计的产码逻辑让C编译器clang终于能发挥出全部优化潜能,不再被原先偏保守的中间表示卡住。即便如此,HotSpot仍然在两个测试上打败了手工写好的C代码,这也从侧面印证了这家老牌JIT的功底。
性能翻盘的同时,内存曲线来得更漂亮。GC压力和常驻内存占用都有显著下降,不过团队也直言,这次更新涉及代码生成、分配器和回收器的深层变动,是一次“大规模改动”,风险不容忽视。新优化本周已经落地,所有提交都在持续的测试套件中通过了二进制一致性校验,63条测试管线覆盖了并发信号停止模式和协作式调度,无论端口离VM内核多远,暴露出的bug一概修补干净。团队提醒,如果更新后出现构建异常,建议用版本化构建切回上一个稳定版,并反馈问题。
热门跟贴