Java 使用CriticalNative加速JNI调用
众所周知,Java的JNI调用会有很昂贵的固有开销,这主要是出自一系列的安全检查,在Java设计之初,开发者希望将JVM打造成一个与外界互相隔离的铜墙铁壁(别忘天国的Java Applet),因此在JNI调用中会有大量的检查,栈爆上的这篇回复解释了JNI为何"如此之慢"的原因,在正式调用一个C/C++函数之前和之后共需要15步额外的工作! 而且这还不包括额外的数据校验工作,在通过JNI向外传出对象或数组时Java会进行额外的检查,这又更进一步降低了性能. 因此在性能关键的情境中JNI很少被使用,这些年间曾涌现过一些解决JNI开销的方法,比如CriticalArray或NIO的DirectBuffer等,但效果都很有限.
事实上龟壳对JNI效率低的问题也很捉急,因此在Java7时代龟壳在Hotspot中推出过一个未公开的功能: CriticalNative. 说到CriticalNative,首先要先解释下它的老前辈CriticalArray,在JNI中,"正规"的操作数组的方式是使用GetXXXArrayElements和ReleaseXXXArrayElements,然而用过的人都会知道它是慢的有多吃屎,这是因为开发者考虑到在数组操作时可能发生GC导致数组在内存中的位置发生变化,以及直接将Java堆上的内存地址交给用户有些不安全,因此GetXXXArrayElements返回给用户的是一个数组副本,而ReleaseXXXArrayElements则是将副本复制回Java堆中真实的数组里. 而CriticalArray则是为了解决数组副本问题,它是通过在GetPrimitiveArrayCritical和ReleasePrimitiveArrayCritical中创建一个阻止GC的临界区,得以将数组的真实数据直接暴露给用户.
而CriticalNative则是在此之上更进一步,它是一种特殊的JNI函数,整个函数都是一个临界区(当然,也包括跳过一些非关键的安全检查),能够以牺牲JVM整体稳定性获取最大的性能. 由于最初是被设计为JRE的加密模块使用,考虑到现在的加密算法大多以块为单位,换句话说大多数情况下需要在JNI中频繁传递小规模的数组,CriticalNative被专门设计对数组的传递进行优化.
想让一个JNI函数成为CriticalNative,需要如下修改/条件:
-
JRE7或更高版本下的Hotspot虚拟机
-
JNI函数的前缀由"Java_"改为"JavaCritical_"
-
必须是static方法,不能有synchronized
-
参数中不能有对象、对象数组或多维数组
-
原先的普通版本("Java_"开头的)不能去掉
在成为CriticalNative后,函数有如下特性.
-
参数中没有了JNIEnv*和jclass/jobject,基本类型参数不变,数组分成2个参数,头一个参数为jint,代表数组长度,后一个参数为jXXX*,即相应类型的指针
-
由于没有了JNIEnv,显然函数中无法调用任何Java的东西
-
整个函数成为临界区,会阻碍垃圾回收的进行
此外,CriticalNative还有个奇(keng)特(die)的特性,就是懒加载,在最初的一定次数调用中,JVM始终调用的是正常版本,只有达到一定阈值后,才会开始调用CriticalNative版本,这个特性当初也把我坑过几次.这个阈值和时间无关,只与调用次数有关.
举个栗子,以一个在Java中通过SSE计算两个4x4矩阵乘法的native方法为例,如果那个方法名字叫mul,位于mypackage包中的MyClass类中,没有其他形式的重载,参数是两个float[],那么它的标准JNI函数应该是.
JNIEXPORT void JNICALL Java_mypackage_MyClass_mul(
JNIEnv *env, jclass klass, jfloatArray mat1, jfloatArray mat2)
{
float *A = static_cast<float*>(env->GetPrimitiveArrayCritical(mat1, 0));
float *B = static_cast<float*>(env->GetPrimitiveArrayCritical(mat2, 0));
sseMul(A, B); //计算乘法
env->ReleasePrimitiveArrayCritical(mat1, A, 0);
env->ReleasePrimitiveArrayCritical(mat2, B, JNI_ABORT);
}
如果要添加它的CriticalNative形式,那就在保留原函数的同时,再额外加一个:
JNIEXPORT void JNICALL JavaCritical_mypackage_MyClass_mul(
jint length1, jfloat* mat1, jint length2, jfloat* mat2)
{
sseMul(mat1, mat2);
}
然后就无需任何额外的工作了,在Hotspot虚拟机中,最初调用mul函数时会依旧调用标准版本,当总调用次数达到一定次数时,就会开始调用Critical版本,在我的机器上,标准版本的耗时约为61.2ns,Critical版本的耗时约为14.6ns,其中SSE运算占6ns,作为对比,纯Java实现的4x4矩阵乘法耗时约为25.6ns.
作为缺点,除了在CriticalNative中无法使用JNIEnv和对象与字符串参数、在调用时系统无法进行GC以外,CriticalNative最大的缺点恐怕是只能在Java7以及更高版本的Hotspot中工作,不过龟壳也在努力改变这个问题,Project Panama便是要大幅优化JNI调用,据说它最新的原型已经可以在JIT中生成JNI函数的直接调用了,不过显然它赶不上今年5月的Java9特性冻结,甚至能否加入Java10都是一个未知数,不管怎么样,祝他们好运.
参考:
栈爆上"爆料"CriticalNative的原帖
JDK Bug System上对CriticalNative的介绍