之所以把这两种语言放到一起讨论，是因为在某些场景下，他们的行为非常相似。
- 他们都通过源文件生成机器码
- 他们都利用vm解释机器码完成程序运行
在绝大多数场景下，Java编译生成的出来的机器码，是由JVM解释运行的；同样python会在运行时将源码编译成机器码，再由python来解释运行，我姑且把他俩都称为解释型语言。
理论上，一个代码工程如果完全由JAVA或者python的源码与机器码构成，那么代码本身不关心自己所运行的芯片平台。
但仍然有一些常用的天然特性其实是区分平台的，例如java中的NIO在linux上调用epoll，而windows上则调用了IOCP；python的绝大多数数学运算库，scipy、numpy中的核心算法部分都使用C、Fortran编写。而他们恰恰就是Java语言的主要应用场景——web应用和python语言的主要应用场景——AI/数学计算中最至关重要的部分。
JAVA部分
Java社区对Armv8指令集的支持相对完整，这里是JVM的支持体系列表，我们使用JDK 8时，就已经可以支持JVM的全部主要功能了。
|
x86/64 |
aarch64 |
arm(32-bit) |
||
|
VMs |
Client |
Yes |
No |
Yes |
|
Server |
Yes |
Yes |
Yes |
|
|
Minimal |
Yes (32 bit) |
Yes, since JDK 12 |
Yes |
|
|
JIT |
C1 |
Yes |
Yes |
Yes |
|
C2 |
Yes |
Yes |
Yes |
|
|
TieredCompilation |
Yes |
Yes |
Yes |
|
|
Graal JIT (Experimental) |
Yes, since JDK 10 |
Yes, since JDK 11 |
No |
|
|
GC |
SerialGC |
Yes |
Yes |
Yes |
|
ParallelGC |
Yes |
Yes |
Yes |
|
|
CMS |
Yes, Deprecated |
Yes, Deprecated |
Yes, Deprecated |
|
|
G1 |
Yes |
Yes |
Yes |
|
|
ZGC |
Experimental |
In development |
No |
|
|
Runtime |
Container support |
Yes |
Yes |
Yes |
|
AppCDS |
Yes |
Yes, since JDK 10 |
Yes, since JDK 10 |
|
|
HugePages |
Yes |
Yes |
Yes |
|
|
Numa Support |
Yes |
Yes |
No |
|
|
Serviceability |
Java Flight Recorder |
Yes |
Yes, since JDK 11 |
Yes, since JDK 11 |
Table1 JVM端口功能对照表
JAVA字节码在执行过程中，JIT会对热点的字节码进行优化编译，编译成机器码后存放在Code Cache区域。如果Code Cache区域满了，那么会导致部分或者全部的代码仅仅通过对字节码逐条解释运行，进而导致JAVA程序性能大减但主机和进程无任何明显的指标异常。由于Armv8是简单指令集，JAVA for Arm64的机器码的体积会数倍于X86，而且部分版本的JVM有Bug，一旦Code Cache满了，则所有的编译功能都会被停止。
防止CodeCache满，需要调整JVM的一些扩展配置，以之相关的扩展配置项主要有：
XXTieredCompilation 多级编译，OpenJDK 7与OracleJDK7 for Arm64版本默认是true，OpenJDK 7与OracleJDK 7for x86上是false，JDK8都是默认为true。由于默认开启了这个配置，会导致Code Cache中存放有多个层级的机器码，机器码体积倍增。关闭后JVM会只开启C2 Compilor线程进行机器码编译，大大降低Code Cache的消耗。
XXReservedCodeCacheSize 默认值与JDK版本和平台有关，从48M到240M不等。对内存成本考虑不高的情况下，建议可以设置大一些，如512MB，这样可以有效防止因为Code Cache区域内存溢出导致JVM性能下降。
Python部分
python的开源社区比java的要松散许多，社区官方也没有意图收编很多看起来属于基本功能的模块，故而想要厘清python对Armv8指令集的支持情况其实非常困难，因为仅仅python本体能够支持Armv8并没有太大意义。粗浅的打个比方，python在如今的代码世界里，更多的是充当胶水，越来越多的功能其实不是由python native的代码编写。如果python生态中的许多功能模块不支持Armv8，空有一瓶好胶水其实也是没有用的。
不过经过实测，使用python2.7.9、python3.5在鲲鹏服务器上运行完整的Openstack应用（Nova、Cinder、Swift、Glance、Neutron、Ceilometer等等），所有功能和测试用例都是正常的，因此可以相对乐观的认为，python2.7.9和python3在鲲鹏上的兼容性是具备的。
转载自鲲鹏社区 作者：太一