The performance of JVM and Java applications of the same version differs by 30% on X86 and aarch64 platforms. Why?

Song Baohua 2021-09-15 09:51:18
performance jvm java applications version


Editor's note : At present, many companies use x86 and AArch64 2 A mainstream server . The computational power of these two environments is equal , With the same memory : The same version of JVM and Java application , same JVM Parameters , The performance of application is different in different platforms 30%,x86 Much better than AArch64 platform . This paper analyzes an application in AArch64 Examples of performance degradation on the platform , Find out JVM Of CodeCache Size is the root cause of this performance problem , And then study what leads to... On different platforms CodeCache Different sizes . Finally, the author gives how to set parameters in different platforms to avoid this problem . I hope this article can give readers some enlightenment : When using different hardware platforms, we need to pay attention to the impact of the underlying hardware on the upper application .

The business is in x86 and AArch64 When deployed simultaneously on ( same JDK and Java Application version ), Find out AArch64 Platform performance degradation is a serious problem . Check the log further , Found in AArch64 The following situations happen occasionally in the platform :

This represents JVM Medium CodeCache Full of , Cause compilation to stop , Uncompiled methods can only interpret and execute , This will seriously affect the application performance . What is CodeCache

CodeCache What is it?

Simply speaking ,CodeCache Used to store compiled methods , It is divided into three parts :

  1. Non-nmethods: Include runtime Stub,Adapter etc. ;

  2. Profiled nmethod: Including methods of collecting information , That is... In layered compilation 2、3 Layer method ;

  3. Non-Profiled nmethods: Including methods that do not collect information , That is... In layered compilation 1、4 Layer method , Also include JNI Methods .

notes : Layered compilation refers to JVM At the same time C1 and C2 Two compilers ,C1 Do some simple compilation optimization , Less time consuming ,C2 Do more complex compilation optimization , Good performance , Compilation takes a lot of time . Layered compilation is triggered in JVM It will be triggered according to the corresponding conditions , For more knowledge about layered compilation, you can refer to relevant resources [1].

stay JDK 9 after [2], These will be assigned to different areas ( Advantages of using different areas : lookup 、 Recycling etc. ),JDK 8 Will be assigned to the same area .

JVM I usually clean up some unreachable methods , For example, dead methods due to backoff optimization , in addition UseCodeCacheFlushing Options ( Default on ), It also cleans up older and less executed methods . once CodeCache After full , Will stop compiling , until CodeCache Space available , If closed UseCodeCacheFlushing Options , Will directly and permanently stop compiling .

Different JVM Version and different parameters , default CodeCache Different sizes .JDK 11 Under the default parameters in CodeCache The size is 240M, If you want to get ( confirm ) By default CodeCache size , It is recommended to use - XX:+PrintFlagsFinal Options get ReservedCodeCache Size .

CodeCache The size is mainly adjusted through the following options :

Option Description
InitialCodeCacheSize Initial CodeCache size ( Unit byte )
ReservedCodeCacheSize Reserved CodeCache size , That is, the biggest CodeCache size ( Unit byte )
CodeCacheExpansionSize CodeCache Each expansion size ( Unit byte )

Use –XX:+PrintCodeCache Option to print the... Used by the application CodeCache situation , as follows :

among max_used Indicates... Used in the application CodeCache size , According to this, you can set the appropriate ReservedCodeCacheSize value .

AArch64 vs x86_64

We all know AArch64 and x86 Respectively RISC and CISC framework , Therefore, there are some differences in code density , In this article [3] The size of handwritten assembly under different instruction sets is compared , You can see AArch64 The code density is RISC Better in the architecture , But compared with x86_64 Still a little worse ( among RISC The worst ,m68k best ).

In addition, the author selects java Test Suite dacapo[4] Compare AArch64 and x86_64 Next CodeCache The size of the occupation .

You can see , stay AArch64 Under the architecture ,CodeCache Average ratio x86_64 Be big , But according to different scenarios , The size gap is different , stay 5%-20% Between . So we found the same application in x86 and AArch64 Upper time ,CodeCache The size needs to be adjusted accordingly .

besides , Attention is also needed InlineSmallCode Options ,JVM It's just inline Methods with code volume smaller than this value .JVM adopt inline Can trigger more optimizations , therefore inline It is also important for performance improvement . stay JDK 11 in ,InlineSmallCode stay x86 The default value under is 2000 byte , stay AArch64 The default value under is 2500 byte . and JDK 8 in ,InlineSmallCode stay x86 and AArch64 The default values are 2000 byte . Therefore, it is recommended to modify it during migration InlineSmallCode Value . Business through to CodeCache Adjustment of relevant parameters , Achieve assistance JIT The best compilation effect .

Postscript

If you encounter related technical problems ( Including but not limited to Bi Sheng JDK), You can enter Bisheng JDK Find relevant resources in the community ( Click on the original Enter official website ), Including binary downloads 、 Code warehouse 、 Use teaching 、 install 、 Learning materials, etc . Bi Sheng JDK The community holds regular technical meetings every two weeks on Tuesdays , At the same time, there is a technical exchange group to discuss GCC、LLVM、JDK and V8 And other related compilation techniques , Interested students can add the following wechat assistant , reply Compiler The group of .

Reference resources

[1]http://cr.openjdk.java.net/~thartmann/talks/2017-hotspot_under_the_hood.pdf

[2]https://bugs.openjdk.java.net/browse/jdk-8015774

[3]http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf

[4]http://dacapobench.org/

版权声明
本文为[Song Baohua]所创,转载请带上原文链接,感谢
https://javamana.com/2021/09/20210909145259967I.html

  1. The first starcoin & move hacksong source code analysis - P (a)
  2. Zhaijia 36 days Salt Fish turn into Tencent, Zookeeper Consistency level analysis,
  3. Traitement de l'interception des champs de demande communs de Spring Cloud, plus de 500 personnes interviewent Ali,
  4. About JavaScript modules
  5. Object oriented programming (2)
  6. Java日期时间API系列42-----一种高效的中文日期格式化和解析方法
  7. Java日期時間API系列42-----一種高效的中文日期格式化和解析方法
  8. 宅家36天鹹魚翻身入職騰訊,Zookeeper一致性級別分析,
  9. Java Date Time API Series 42 - - a efficient Chinese Date Format and Analysis Method
  10. 已成功拿下字节、腾讯、脉脉offer,7年老Java一次操蛋的面试经历,
  11. 小米Java社招面试,每次面试必问的二叉树的设计与编码,
  12. 小米Java校招面试,阿里、百度、美团、携程、蚂蚁面经分享,
  13. 小米Java校招面試,阿裏、百度、美團、攜程、螞蟻面經分享,
  14. Xiaomi Java School Recruitment interview, Ali, baidu, meituan, ctrip, ant Facebook Sharing,
  15. La conception et le codage de l'arbre binaire requis pour chaque entrevue d'embauche de la société Java millet;
  16. A remporté avec succès Byte, Tencent, Pulse offer, 7 ans Java une expérience d'entrevue de baise,
  17. 干货来袭,Java岗面试12家大厂成功跳槽,
  18. 常用Java框架面试题目,现在做Java开发有前途吗?
  19. 常用Java框架面試題目,現在做Java開發有前途嗎?
  20. Les questions d'entrevue couramment utilisées pour le cadre Java sont - elles prometteuses pour le développement Java?
  21. L'arrivée de marchandises sèches, l'entretien d'emploi Java 12 grandes usines ont réussi à changer d'emploi,
  22. Multiple postures for handling container time in k8s environment
  23. Echarts remove left Gap, Blank
  24. Hotspot Weekly | zoom $100 million, docker fees, $38 billion Data bricks
  25. JsonMappingException: No serializer found for class org.apache.ibatis.executor.loader.javassist.JavassistProxyFactory...
  26. Java. Security. Securerandom source code analysis Java. Security. EGD = file: / dev /. / urandom
  27. When using IntelliJ idea, jump directly and quickly from the mapper interface to mapper.xml
  28. When idea writes SQL in mybatis XML, the solution to the problems of table name, field and red reporting
  29. Spring cloud integrates Nacos
  30. 应届毕业生Java笔试题目,2021大厂Java社招最全面试题,
  31. Liver explosion! Take you to understand Hadoop serialization
  32. linux系列之:告诉他,他根本不懂kill
  33. java版gRPC实战之三:服务端流
  34. RabbitMQ核心知识总结!
  35. linux系列之:告诉他,他根本不懂kill
  36. java版gRPC实战之三:服务端流
  37. RabbitMQ核心知识总结!
  38. 10天拿到字节跳动Java岗位offer,学习Java开发的步骤
  39. 10天拿到字节跳动Java岗位offer,Java知识点思维导图
  40. Résumé des connaissances de base de rabbitmq!
  41. 10天拿到字節跳動Java崗比特offer,Java知識點思維導圖
  42. 10 jours pour obtenir un Byte Jump Java post offer, Java Knowledge point Mind Map
  43. 10 jours pour obtenir l'octet Jump Java post offer, apprendre les étapes du développement Java
  44. Java version of gppc Reality Three: server side stream
  45. Linux Series: Dites - lui qu'il ne connaît pas kill du tout
  46. "Data structure and algorithm" of front end -- binary search
  47. 2020-2021京东Java面试真题解析,如何才能通过一线互联网公司面试
  48. 13 SpringBoot整合RocketMQ实现过滤消息-根据SQL表达式过滤消息
  49. 12 SpringBoot整合RocketMQ实现过滤消息-根据TAG方式过滤消息
  50. 11 SpringBoot整合RocketMQ实现事务消息
  51. 11 springboot Consolidated rocketmq Implementation transaction message
  52. 12 springboot Consolidated rocketmq Implements Filtering messages - Filtering messages according to tag method
  53. 13 springboot Consolidated rocketmq Implementation Filtering messages - Filtering messages according to SQL expressions
  54. linux系列之:告诉他,他根本不懂kill
  55. (1)java Spring Cloud+Spring boot企业快速开发架构之微服务是什么?它的优缺点有哪些?
  56. Oracle 检查 DATE 列 RANGE 分区表已有分区的最大日期时间
  57. ConcurrentHashMap--原理
  58. 2020 - 2021 JD Java interview Real question Analysis, How can interview through First - Line Internet Company
  59. Concurrenthashmap - - Principes
  60. Oracle vérifie l'heure de date maximale d'une partition existante dans la colonne date