竹笋

首页 » 问答 » 环境 » 华为毕昇JDK8u29211011
TUhjnbcbe - 2022/11/14 17:03:00

年6月30日,毕昇JDKupdateQ2版本正式发布,下载方式见文末参考链接。该版本在同步OpenJDK社区8u/11.0.11的基础上,还包含如下更新,为用户提供高性能、可用于生产环境的OpenJDK发行版。

提供鲲鹏硬件加速的KAEProvider支持DH,RSA签名等众多算法(毕昇JDK8)

Jmap并行扫描优化支持CMS(毕昇JDK8,毕昇JDK11)

G1GC实现numa-aware特性(毕昇JDK8)

G1GCnuma-aware优化(毕昇JDK11)

Bugfixes

鲲鹏硬件加速的KAEProvider(毕昇JDK8)

KAE(KunpengAccelerateEngine)加解密是鲲鹏处理器提供的硬件加速方案,可以显著降低处理器消耗,提高处理器效率.毕昇JDK8u为Java用户提供了KAEProvider,使Java开发人员可以直接使用硬件带来的加速效果,但支持算法有限。此版本在的基础上,新增DH、ECDH、RSA签名、AES-GCM等算法,有效提升应用在HTTPS中的处理性能。同时提供对国密算法SM3和SM4的支持,其中SM4支持ECB/CBC/CTR/OFB模式。

到目前为止,毕昇JDK除了默认Provider不支持的加密模式外(例如AES/XTS模式),已支持KAE硬件加速引擎中的所有加解密算法,KAEProvider具体实现的算法如下:

实现

KAEProvider的实现原理在前期已有介绍,详见openEuler21.03特性解读

毕昇JDK8支持鲲鹏硬件加解密特性详解和使用介绍.简而言之,KAEProvider通过实现JDK中的特定的SPI(ServiceProviderInterface)接口支持具体的算法,此版本实现的SPI类如下:

除此之外,毕昇JDK为用户提供$JAVA_HOME/lib/ext/kaeprovider.conf文件,方便用户启动或关闭KAEProvider中的某些算法,默认启用所有算法,文件内容如下:

用户也可通过打开此文件的日志选项,来查看是否检测到了机器上的kae引擎。如果打开了此选项,并在用户的机器上检测到了kae引擎,则会将日志写入进程启动目录下的kae.log文件,如下所示:

性能测试

测试环境:

CPU:Kunpeng

OS:openEuler20.03

KAE:v1.3.10

JDK:毕昇JDK1.8.0_

JMH

测试用例请参加毕昇JDK代码仓[3].

如下为DH的测试结果,可以看到与JDK默认的Provider相比,当秘钥长度为时,平均性能提升%;当秘钥长度为时,平均性能提升%:

如下为RSAPSS签名的测试结果,可以看到与JDK默认的Provider签名1k的数据相比,当秘钥长度为时,平均性能提升%,当秘钥长度为时,平均性能提升%.

HTTPS

服务端Tomcat:9.0.46

客户端Jmeter:5.4.1

步骤:

Tomcat:默认Provider/KAEProvider

Jmeter:默认Provider

默认Provider的结果如下:

KAEProvider的结果如下:

结论:与JDK默认的Provider相比,在HTTPS短连接场景下,KAEProvider可以提升93%.

Jmap并行扫描优化支持CMS(毕昇JDK8,毕昇JDK11)

背景

当前jmap采用单线程对java堆进行扫描,扫描速度较慢,并且对超大堆进行扫描时(大于G),容易引起系统卡死。因此可以通过多线程来进行扫描,减少卡顿时间。之前发布的版本支持了G1GC与ParallelGC并行扫描,本次发布增加对CMSGC的支持。

实现

毕昇JDK在社区高版本jmap优化回合的基础上,在cmsheap上部署CMSHeapBlockClaimer用来为每个线程分配heapblock,增加了object_iterate_block接口用来扫描block中的object,每个线程的扫描结果会在已有的heap_inspection模块中的ParHeapInspectTask进行合并。具体包含内容如下:

整体扫描策略:可用的GC线程(active_workers)有两个用来扫描年轻代,一个扫描suvivor区,另一个扫描eden区;剩下的线程全部用来扫描老年代。

GC线程任务划分:在CMSHeap模块中新增CMSHeapBlockClaimer类,提供claim_and_get_block接口用来为每一个线程生成唯一的block_index,GC线程根据block_index来确定自己要扫描的区域。

年轻代扫描策略:年轻代的eden(block_index=0)跟survivor(block_index=1)区会被分别当做一个整体的block,GC线程扫描时沿用现有的扫描接口object_iterate。

老年代扫描策略:+老年代被分成一个个1M大小的block,block大小由参数IterateBlockSize决定。+在ConcurrentMarkSweepGeneration中新增object_iterate_block方法来扫描block。

用户可通过在jmap-histo后增加parallel参数来使用此特性,如下所示:

jmap-histo:live,parallel=3pid:指定并行线程数为3

jmap-histo:live,parallel=0pid:使用当前系统可支持的并行线程数(-XX:ParallelGCThreads)

jmap-histo:live,parallel=1pid:使用原有的串行扫描

性能测试

测试环境:

CPU:Kunpeng

OS:openEuler20.03

JDK:毕昇JDK1.8.0_、毕昇JDK11.0.11

在对约60G大小的堆进行扫描时,可以看到JDK8并行扫描的平均收益在26%左右,JDK11并行扫描的平均收益在31%左右。

G1GC实现NUMA-Aware特性(毕昇JDK8)

背景

在NUMA架构下,跨NUMA节点操作内存相比本NUMA节点操作内存时延会成倍增加。OpenJDK社区在JDK14中合入了G1GCNUMA-Aware特性[4],可以让JAVA用户线程尽可能的操作本NUMA节点上的内存,可以提高G1GC在NUMA架构下的处理性能,但低版本的JDK8和JDK11不支持该特性。

实现

毕昇JDK以前已将社区高版本中的G1NUMA-Aware特性合入到了11.0.8,此次将该特性回合到8u,有效提高G1GC在NUMA架构下的处理性能。具体的实现方式为:在配置的NUMAnode节点(numactl可以配置,不配置就是所有节点)上,均匀分配G1Region,在Young区(Eden和Survivor)申请Region的时候优先选择本节点的Region。

用户只需要通过打开UseNUMA参数即可使用此特性,如下所示:

-XX:+UseG1GC–XX:+UseNUMA

性能测试

SPECjbb是业界通用的Java性能的基准测试[5],测试结果主要分为Max和Critical,其中Max是指最大吞吐量,Critical是指在在限制响应时间下的吞吐量。这里采用SPECjbb对该特性进行测试。

测试环境:

CPU:Kunpeng-,96核

OS:openEuler20.03

内存:G

JDK:毕昇JDK1.8.0_

SPECjbb配置:GROUP_COUNT=1,TI_JVM_COUNT=4

SPECjbb的测试结果如下,可以看到与不开启NUMA相比,开启NUMA后的性能平均提升20%+.

G1GCNUMA-Aware优化(毕昇JDK11)

背景

毕昇JDK11已在11.0.8版本支持G1GCNuma-Aware特性,合入该特性后,G1都尽量在线程所属的NUMAnode上去分配内存,当线程所属Node上的内存不够分配或者在指定的遍历次数达到后,如果没有获取到所属node上的内存时就会随机从空闲的链表上取一个region,而这种随机选择的不一定是最优的。

实现

上图以华为泰山服务器为例,通过numactl--hardware可以显示node间距离值信息,可以看到node自身的距离值是10,node1与node2的距离值是16,node1与node3的距离值是32,数值越小,跨node的访存速度会更快。基于上面背景描述,毕昇JDK11.0.11在毕昇JDK11.0.10的基础上,对G1GCNUMA-Aware特性访存做了持续优化,通过在遍历freeregion链表时,记录到本Node的最小距离的region,最终将距离本线程所属Node最小距离的region分配出去(包含本Node上的region,距离为10),实现内存访问的尽量最优化,达到提升业务性能目的。

用户只需要通过打开UseNUMA参数来使用此特性,如下所示:

-XX:+UseG1GC–XX:+UseNUMA

性能测试

测试环境与上述毕昇JDK8的NUMA-Aware测试环境相同。

SPECjbb的测试结果如下,可以看到与毕昇JDK11.0.10相比,开启NUMA特性后,Critical性能平均提升9%,Max性能无劣化。

Bugfixes

除了上面介绍的一些特性外,毕昇JDK还合入了社区高版本中的一些bugfix和优化的patch,为用户提供稳定、高性能的毕昇JDK。具体回合patch如下:

JDK8

:CMSParScanClosuremissesabarrier

:Missingaarch64partsofJDK-(C1:possibleoverflowwhenstrengthreducingintegermultiplybyconstant)

:Unabletousealgorithmsfrom3pproviders

:ImproveAlgorithmConstraints:checkAlgorithmperformance

JDK11

:CMSParScanClosuremissesabarrier

参考

[1]毕昇JDK8下载:

1
查看完整版本: 华为毕昇JDK8u29211011