0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

在AArch64平台上性能下降的例子

Linux阅码场 来源:openEuler 作者:吴言 2021-09-09 11:11 次阅读

编者按:目前许多公司同时使用 x86 和 AArch64 2 种主流的服务器。这两种环境的算力相当,内存相同的情况下:相同版本的 JVM 和 Java 应用,相同的 JVM 参数,应用性能在不同的平台中表现相差 30%,x86 远好于 AArch64 平台。本文分析了一个应用在 AArch64 平台上性能下降的例子,发现 JVM 的 CodeCache 大小是引起这个性能问题的根源,进而研究什么导致了不同平台上 CodeCache 大小的不同。最后笔者给出了不同平台中该如何设置参数规避该问题。希望本文能给读者一些启示:当使用不同的硬件平台时需要关注底层硬件对于上层应用的影响。

业务在 x86 和 AArch64 上同时部署时(相同的 JDK 和 Java 应用版本),发现 AArch64 平台性能下降严重问题。进一步查看日志,发现在 AArch64 平台中偶有如下情况:

这代表 JVM 中的 CodeCache 满了,导致编译停止,未编译的方法只能解释执行,进而严重影响应用性能。那什么是 CodeCache?

CodeCache 是什么

简单来说,CodeCache 用于存放编译后的方法,主要分为三部分:

Non-nmethods:包括运行时 Stub,Adapter 等;

Profiled nmethod:包括会采集信息的方法,即分层编译中第 2、3 层的方法;

Non-Profiled nmethods:包括不采集信息的方法,即分层编译中第 1、4 层的方法,也包括 JNI 的方法。

注:分层编译指的是 JVM 同时存在 C1 和 C2 两种编译器,C1 做一些简单的编译优化,耗时较短,C2 做更多复杂的编译优化,性能较好,编译耗时较多。分层编译的触发在 JVM 内会根据相应的条件进行触发,关于更多分层编译相关知识可以参考相关资料 [1]。

在 JDK 9 之后 [2],这些会分配到不同的区域(使用不同区域的优点:查找、回收等),JDK 8 中会分配到同一块区域。

JVM 平时会清理一些不可达的方法,例如由于退优化等产生的死方法,另外 UseCodeCacheFlushing 选项(默认开启),还会清理较老以及执行较少的方法。一旦 CodeCache 满了之后,会停止编译,直到 CodeCache 有空间,若关闭了 UseCodeCacheFlushing 选项,则会直接永久停止编译。

不同的 JVM 版本以及不同的参数,默认的 CodeCache 大小不同。JDK 11 中默认参数下 CodeCache 大小为 240M,若想获取(确认)默认情况下的 CodeCache 大小,建议使用 - XX:+PrintFlagsFinal 选项获取 ReservedCodeCache 的大小。

CodeCache 大小主要通过以下选项调节:

InitialCodeCacheSize 初始的 CodeCache 大小(单位字节)
ReservedCodeCacheSize 预留的 CodeCache 大小,即最大CodeCache 大小(单位字节)
CodeCacheExpansionSize CodeCache 每次扩展大小(单位字节)
Option Description

使用–XX:+PrintCodeCache 选项可以打印应用使用的 CodeCache 情况,如下:

其中 max_used 表示应用中使用到的 CodeCache 大小,据此可以设置合适的 ReservedCodeCacheSize 值。

AArch64 vs x86_64

我们都知道 AArch64 和 x86 分别为 RISC 和 CISC 架构,因此代码密度方面存在一定差异,在这篇文章 [3] 中比较了不同指令集下手写汇编的大小,可以看到 AArch64 的代码密度是 RISC 架构中较优的,但相比 x86_64 仍稍差些(其中 RISC 最差,m68k 最好)。

另外笔者选用业界通用的 java 测试套 dacapo[4] 比较 AArch64 和 x86_64 下 CodeCache 占用的大小。

可以看到,在 AArch64 架构下,CodeCache 均比 x86_64 要大,但根据不同场景,大小差距不同,在 5%-20% 之间。因此在我们发现相同应用在 x86 和 AArch64 上时,CodeCache 大小需要进行相应的调节。

除此之外,还需要注意 InlineSmallCode 选项,JVM 只会 inline 代码体积比该值小的方法。JVM 通过 inline 可以触发更多的优化,因此 inline 对于性能提升也很重要。在 JDK 11 中,InlineSmallCode 在 x86 下的默认值为 2000 字节,在 AArch64 下的默认值为 2500 字节。而 JDK 8 中,InlineSmallCode 在 x86 和 AArch64 下默认值均为 2000 字节。因此建议迁移时也相应修改 InlineSmallCode 的值。业务通过对 CodeCache 相关参数的调整,达到助力 JIT 的最佳编译效果。

后记

如果遇到相关技术问题(包括不限于毕昇 JDK),可以进入毕昇 JDK 社区查找相关资源(点击原文进入官网),包括二进制下载、代码仓库、使用教学、安装、学习资料等。毕昇 JDK 社区每双周周二举行技术例会,同时有一个技术交流群讨论 GCC、LLVM、JDK 和 V8 等相关编译技术,感兴趣的同学可以添加如下微信小助手,回复 Compiler 入群。

责任编辑:haq

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 服务器
    +关注

    关注

    12

    文章

    9013

    浏览量

    85165
  • JAVA
    +关注

    关注

    19

    文章

    2957

    浏览量

    104534
  • JVM
    JVM
    +关注

    关注

    0

    文章

    157

    浏览量

    12206

原文标题:相同版本 JVM 和 Java 应用,在 x86 和AArch64 平台性能相差30%,何故?

文章出处:【微信号:LinuxDev,微信公众号:Linux阅码场】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    基于TMS320C64x的DSP平台上运行TMS320C64x编解码器

    电子发烧友网站提供《基于TMS320C64x的DSP平台上运行TMS320C64x编解码器.pdf》资料免费下载
    发表于 10-14 11:16 0次下载
    <b class='flag-5'>在</b>基于TMS320C<b class='flag-5'>64</b>x的DSP<b class='flag-5'>平台上</b>运行TMS320C<b class='flag-5'>64</b>x编解码器

    【飞凌嵌入式OK3576-C开发板体验】RKNN神经网络-YOLO目标检测

    使用yolov5s_relu.rknn 五、RKNN C Demo程序 5.1、板端linux系统 以 Linux 系统(aarch64 架构)的 RK356x 平台为例,需要使用 rknn_model_zoo 目录
    发表于 10-10 09:33

    请问TLV320ADC6140NXP的iMX6UL平台上如何配置route?

    我正在尝试NXP的iMX6UL平台上Linux 4.1.15版本,使用TLV320ADC6140作为音频的codec输入。 此外,我同时使用了两个TLV320ADC6140做
    发表于 09-30 06:09

    STM32平台新选择:Nand Flash(贴片TF卡)的应用解析

    MK米客方德SD NAND的高性能和高可靠性,使其成为STM32平台上理想的存储解决方案。它的广泛应用不仅提升了嵌入式系统的性能,也为未来的技术创新和应用拓展提供了坚实的基础。
    的头像 发表于 09-18 11:04 624次阅读
    STM32<b class='flag-5'>平台</b>新选择:Nand Flash(贴片TF卡)的应用解析

    MK米客方德SD NAND:STM32平台上的存储方案

    STM32平台上,SD卡的重要性不言而喻,它为嵌入式系统提供了必要的数据存储和读写能力。MK米客方德SD作为市场上的一种选择,因其耐用性、较小的体积以及高速的传输性能STM32
    的头像 发表于 08-26 10:23 602次阅读
    MK米客方德SD NAND:STM32<b class='flag-5'>平台上</b>的存储方案

    第四章: PC 交叉编译 aarch64 的 tensorflow 开发环境并测试

    本文介绍了 PC 端交叉编译 aarch64 平台的 tensorflow 库而非 tensorflow lite 的心酸过程。
    的头像 发表于 08-25 11:38 796次阅读
    第四章:<b class='flag-5'>在</b> PC 交叉编译 <b class='flag-5'>aarch64</b> 的 tensorflow 开发环境并测试

    飞凌OK-全志T527开发板nbench性能测试

    和一运行Linux的AMD K6-233电脑比较,得到的比值作为性能指数。由于是完全开源的,爱好者可以各种平台和操作系统运行Nbenc
    发表于 08-20 10:25

    深度学习算法嵌入式平台上的部署

    随着人工智能技术的飞速发展,深度学习算法各个领域的应用日益广泛。然而,将深度学习算法部署到资源受限的嵌入式平台上,仍然是一个具有挑战性的任务。本文将从嵌入式平台的特点、深度学习算法的优化、部署流程、代码示例以及面临的挑战和未来
    的头像 发表于 07-15 10:03 1160次阅读

    arduino平台上开发esp32c3,twai队列异常的原因?

    arduino平台上开发esp32c3。采用了freertos创建了几个任务。主要有主循环loop和CAN数据读写任务。主循环的优先级高于CAN读写任务。现在的问题是我CAN任务执行完毕检查
    发表于 06-11 06:16

    用ISD平台建立工程后,有软件可以把ISD平台上编译后生成的文件用imontionlink直接烧录进芯片吗?

    用ISD平台建立工程后,ISD平台上有烧录程序的入口,有软件可以把ISD平台上编译后生成的文件用imontionlink直接烧录进芯片吗
    发表于 05-20 07:44

    Arm Neoverse驱动的基础设施构建云软件的未来

    为了向开发者提供一个支持 AArch64 架构的开源项目和独立软件开发商 (ISV) 资源库,我们很高兴地推出 Software Ecosystem Dashboard(软件生态系统可视化工具)。
    的头像 发表于 05-14 14:06 387次阅读
    <b class='flag-5'>在</b>Arm Neoverse驱动的基础设施<b class='flag-5'>上</b>构建云软件的未来

    能在Meteor Lake平台上使用SDK 3.5吗?

    SDK 是 3.6 版,不支持 CYPD6127 部件。 那么,我能在 Meteor Lake 平台上使用 SDK 3.5 吗? SDK 3.5 - 平台选择有"MTL" 关键字 :
    发表于 03-04 06:32

    把CY8C4146平台上工程移植到CY8C4147平台上,用户程序没运行的原因?

    客户现在想把CY8C4146平台上工程移植到CY8C4147平台上topdesign重新选择4147,管脚也调整了一下,编译重新生成底层代码,creator4.2IDE编译没报错,同时同步更新
    发表于 02-21 06:04

    探索aarch64架构使用ftrace的BPF LSM

    aarch64跟x86_64的内核功能有差异。笔者尝试定位这些差异时,看到这篇文章,可以让大家更直观地了解LSM eBPF两种CPU 内核
    的头像 发表于 01-25 09:30 669次阅读

    中兴车用操作系统SafetyLinuxA1000平台上的适配

    近日,黑芝麻智能A1000芯片基础软件开发在线研讨会在顺利完结直播。研讨会由黑芝麻智能李坤、中兴通讯李玉鹏两位技术专家主讲,主题分别为 《视觉感知数据流在A1000平台上的基础软件开发》 ,以及 《中兴车用操作系统SafetyLinuxA1000
    的头像 发表于 12-19 15:51 895次阅读
    中兴车用操作系统SafetyLinux<b class='flag-5'>在</b>A1000<b class='flag-5'>平台上</b>的适配