正文
摘要
最近一段时间学习jvm比较多.
为了能够更加深入的进行一些调优和峰值性能的配置.
看了很多像是NMT,inline,堆区方法区以及分层编译等知识.
但是看到华为毕昇社区说的codecache相关部分.感觉挺值得学习的
前几天也学习总结了下NMT的知识. 但是感觉可能不是非常系统,这次就继续学习一下.
可能仅是流水账. 希望能够对日后的工作有所帮助. 可能会有很多期
站在高手的肩膀上
毕昇JDK社区有一个帖子专门讲解了 codecache 的配置和aarch64架构下的问题来源.
我这边简单总结一下:
因为aarch64是risc精简指令集, 为了达到x86 这样risc复杂指令集能够实现的功能.
他需要有更多的指令数来完成对应的方法操作.
这也就导致了,同样的一段代码, 在进行jit时. x86编译后的可执行文件的大小(占内存)
会小于aarch64编译后的文件大小.
但是jdk8时 启动程序后的codecache可能是相仿的,就会导致x86能够容纳的jit编译后的方法数量
要大于aarch64的
当codecache满了之后, jvm执行代码会劣化到使用 int 解释进行执行
会导致严重的性能衰退.
基于此需要进行code cache的相关优化操作.
一些自己的理解扩展
衡量一个CPU性能的好坏, 主频仅仅是一个方面
一般理解相似架构的情况下,主频越高性能越好.
不同架构下面, 同频性能就是一个很值得评判CPU厂商能力的指标.
这里很不幸的是, 国内大部分信创CPU厂商都盲目追求 主频的升高.
但是对IPC的提升都比较有限(龙芯因为制程上不去,所以一直说自己IPC有提高)
复杂指令集虽然也可能最后编译成uos 的方式进行执行.
但是一个指令周期内. CISC理论上会比RISC要多干一些事情, 因为可能执行更复杂的指令
aarch64就存在这样的一个问题. 本身完成相同function 就要比 x86 多很多处理器指令.
相同周期内执行的指令可能还不如x86执行的多
所以性能上 aarch64的同频率性能可能只有x86的一半
当然了此处苹果的M系列,因为及其牛B的设计, 尤其是on package的统一内存
并且苹果自研增加的很多缓存,指令优化,以及台积电最好的生产制程导致M1和M2的性能极高.
可以与x86一决高下
但是国内的CPU厂商一方面没有苹果的技术积累. 另一方面没有台积电的制程加成
所以性能要比m系列差不只一倍.
国产当自强
进行NMT简单分析
启动脚本里面增加上一段设置
-XX:NativeMemoryTracking=detail
然后启动服务的过程中编写一段非常简单的循环处理
for i in {1..20000} ; do jcmd 4002199 VM.native_memory > ${i}.txt;echo $i ;sleep 30 ; done
需要注意 为了简单(今天跳绳有点累和困), 我直接获取了启动成功后的线程进行展示.
然后可以查看启动过程中code Codecache的变化
grep -ir code -A 2
可以查看 code 以及后面两行的内容
我分析了aarch64 还有 x86_64的
这里我产生了一个极大的疑问
aarch64的codeCache默认值跟x86_64 不一样,而且反而更小
aarch64
1.txt:- Code (reserved=137027KB, committed=28035KB)
1.txt- (malloc=3907KB #5977)
1.txt- (mmap: reserved=133120KB, committed=24128KB)
172.txt:- Code (reserved=153096KB, committed=121736KB)
172.txt- (malloc=19976KB #26142)
172.txt- (mmap: reserved=133120KB, committed=101760KB)
因为30秒获取一次, 所以 前面几次只有 28M左右的codecache的占用. 但是启动成功后占用了120M左右.
堆区的reserved的内存大小一开始是 128MB. 慢慢增加到了 153MB
感觉跟书本上的不太一致.
对应的x86的统计情况
1.txt:- Code (reserved=260409KB, committed=69505KB)
1.txt- (malloc=10809KB #13261)
1.txt- (mmap: reserved=249600KB, committed=58696KB)
21.txt:- Code (reserved=275395KB, committed=153195KB)
21.txt- (malloc=25795KB #33803)
21.txt- (mmap: reserved=249600KB, committed=127400KB)
发现堆区CodeCache都进行了一定程度的增长
另外统计发现:
启动成功使用了150M的堆区
打开一个功能有可能会增加4M的堆区使用.
所以感觉如果是很多功能的场景需要增加codeCache的大小
简单理解
1. 因为进行C1和C2编译需要有执行调用和回边的次数阙值. 所以产品运行过程中的CodeCache会逐渐增加.
2. 单一模块和全部模块的使用场景也是不一样的. 单一模块可能CodeCache不会要求太多台复杂
但是如果是全模块使用, 可能需要提高CodeCache 避免堆区被占用殆尽.
3. 没有找到扩大CodeCache可能产生负面效果的文档. 感觉在内存没有瓶颈的情况下应该适当增加这个数值
避免因为CodeCache耗尽,JVM不进行jit编译导致性能劣化.
