关于Java：JNI调用的量化开销是多少？

What is the quantitative overhead of making a JNI call?

仅根据性能，大约有多少"简单"的Java行是JNI调用的等效性能命中？

或者尝试以更具体的方式表达问题，如果是一个简单的Java操作，比如

1	someIntVar1 = someIntVar2 + someIntVar3;

如果给定EDOCX1的"cpu-work"索引(0)，那么jni调用开销的典型(ballpark)"cpu-work"索引是什么？

< BR>此问题忽略等待本机代码执行所用的时间。在电话用语中，严格地说是呼叫中的"降旗"部分，而不是"呼叫速率"。

< BR>问这个问题的原因是有一个"经验法则"，知道当知道本地成本(直接测试)和给定操作的Java成本时，何时尝试对JNI调用进行编码。它可以帮助您快速避免编写JNI调用的麻烦，只会发现调用开销消耗了使用本机代码的任何好处。

编辑：

有些人对CPU、RAM等的变化感到迷惑。这些都与问题几乎无关，我要的是Java代码行的相对成本。如果CPU和RAM很差，它们对于Java和JNI都很差，因此环境因素应该平衡。JVM版本也属于"无关"类别。

这个问题不是要求纳秒的绝对计时，而是以"简单Java代码行"为单位的"工作努力"。

相关讨论

快速剖面仪测试得出：

Java类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class Main {
private static native int zero();

private static int testNative() {
return Main.zero();
}

private static int test() {
return 0;
}

public static void main(String[] args) {
testNative();
test();
}

static {
System.loadLibrary("foo");
}
}

C库：

1
2
3
4
5
6
7
8

#include <jni.h>
#include"Main.h"

JNIEXPORT int JNICALL
Java_Main_zero(JNIEnv *env, jobject obj)
{
return 0;
}

结果：

single invocation 10 calls in a loop 100 calls in a loop

系统细节：

1
2
3
4

java version"1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-1)
OpenJDK Server VM (build 23.2-b09, mixed mode)
Linux visor 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 GNU/Linux

更新：X86(32/64位)和ARMV6的Caliper Micro基准如下：

Java类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

public class Main extends SimpleBenchmark {
private static native int zero();
private Random random;
private int[] primes;

public int timeJniCall(int reps) {
int r = 0;
for (int i = 0; i < reps; i++) r += Main.zero();
return r;
}

public int timeAddIntOperation(int reps) {
int p = primes[random.nextInt(1) + 54]; // >= 257
for (int i = 0; i < reps; i++) p += i;
return p;
}

public long timeAddLongOperation(int reps) {
long p = primes[random.nextInt(3) + 54]; // >= 257
long inc = primes[random.nextInt(3) + 4]; // >= 11
for (int i = 0; i < reps; i++) p += inc;
return p;
}

@Override
protected void setUp() throws Exception {
random = new Random();
primes = getPrimes(1000);
}

public static void main(String[] args) {
Runner.main(Main.class, args);
}

public static int[] getPrimes(int limit) {
// returns array of primes under $limit, off-topic here
}

static {
System.loadLibrary("foo");
}
}

结果(x86/i7500/hotspot/linux)：

1
2
3
4
5
6
7
8

Scenario{benchmark=JniCall} 11.34 ns; σ=0.02 ns @ 3 trials
Scenario{benchmark=AddIntOperation} 0.47 ns; σ=0.02 ns @ 10 trials
Scenario{benchmark=AddLongOperation} 0.92 ns; σ=0.02 ns @ 10 trials

benchmark ns linear runtime
JniCall 11.335 ==============================
AddIntOperation 0.466 =
AddLongOperation 0.921 ==

结果(amd64/phenom 960t/hotspot/linux)：

1
2
3
4
5
6
7
8

Scenario{benchmark=JniCall} 6.66 ns; σ=0.22 ns @ 10 trials
Scenario{benchmark=AddIntOperation} 0.29 ns; σ=0.00 ns @ 3 trials
Scenario{benchmark=AddLongOperation} 0.26 ns; σ=0.00 ns @ 3 trials

benchmark ns linear runtime
JniCall 6.657 ==============================
AddIntOperation 0.291 =
AddLongOperation 0.259 =

结果(armv6/bcm2708/zero/linux)：

1
2
3
4
5
6
7
8

Scenario{benchmark=JniCall} 678.59 ns; σ=1.44 ns @ 3 trials
Scenario{benchmark=AddIntOperation} 183.46 ns; σ=0.54 ns @ 3 trials
Scenario{benchmark=AddLongOperation} 199.36 ns; σ=0.65 ns @ 3 trials

benchmark ns linear runtime
JniCall 679 ==============================
AddIntOperation 183 ========
AddLongOperation 199 ========

总结一下，JNI调用似乎相当于典型的(x86)硬件和热点VM上的10-25 Java OPS。毫不奇怪，在优化的零虚拟机下，结果是相当不同的(3-4次操作)。

感谢@giovanni azua和@marko topolnik的参与和提示。

相关讨论

8.5包括test和testnative:/此外，您不想给出这样的性能比较结果。首先，使用profiler，您永远不会比较A的性能比B快，您需要在发布模式和微基准下编译。第二，如果不考虑平均值和分散度，那么这个数字意味着什么都没有，例如8.5，但是变异性是6.8，那么平均运行时间假设是bs。
你马上就要回答这个问题了。尝试以下操作：1)确保JIT已编译测试代码。2)将简单的行添加到Java版本中，直到两个时间相等，然后发布两个调用的"成本"相同的代码。这就是我想要的答案
@乔瓦尼亚祖亚：我不认为这是最后的答案，而是一个热身：)谢谢你的评论(我真的很感激)，它变得有趣了：)
@波希米亚：预先生成的随机集的int加法算简单的算术吗？
@Barti_ddu您不想在这个过程中涉及太多的内存，因为这样会导致缓存未命中(这是一个巨大的区别)。我建议反复添加一个大的ish素数int，从随机生成的初始值开始，并以某种方式使用该值(通常从测试方法返回)。这无法优化，只能使用堆栈。
@马尔科托波尼克：是的，我已经考虑过了；希望我能把手放在上面直到世界末日：)谢谢。
@巴蒂，那就快点，末日就要到了！
@巴蒂：很酷的结果。不过，我和他们之间有麻烦。原来的问题不需要Java调用，而是一个"联机"执行。方法调用非常昂贵，尤其是在Java中。我也不确定，即使是最积极的JIT优化也可能消除所涉及的开销。另一方面，JNI调用总是一个调用，这使得主要的区别，imho。
@亚历克科恩：不能不同意：)我的出发点是比较两个尽可能相似的调用(native/jni)。
所以您的结果显示JNI调用大约是24个int操作还是12个long操作？我有这个权利吗？
@波西米亚人：事实上，我不敢用那种精确性：)不管怎样，我已经更新了答案。
@Bohemian&；Barti ddu：在我看来，在讨论中得出的"运营中的"结论并不像最初问题要求的那样灵活正确或有用，因为循环本身的操作(而不仅仅是循环体中执行的操作)正在进行基准测试，而不是考虑到"运营"中的因素。正在得出S的结论。我对这个问题的答案很感兴趣，所以我希望自己进行一些基准测试并发布一个答案。(希望我能在现有的答案中找到我的好奇心的答案——噢！)
(我没有评论它，因为它似乎只是一个草案/WIP基准和卡尺一个是真实的，但我真的应该提到：本地调用顶级(非卡尺)基准的度量实际上是测量JNI调用加上JVM调用(IIRC它可能还有其他问题))。

所以我在Windows8.1、64位上测试了JNI调用C的"延迟"，使用EclipseMars IDE、JDK 1.8.0_74和带有配置文件启动插件的VirtualVM Profiler 1.3.8。

设置：(两种方法)
something()传递参数、执行操作并返回参数
nothing()传递相同的参数，对它们不做任何操作，并返回相同的参数。

(每个被呼叫270次)
something()的总运行时间：6523ms
无内容的总运行时间()：0.102ms

因此，在我的例子中，JNI调用是可以忽略的。

相关讨论

实际上，您应该自己测试"延迟"是什么。延迟在工程中定义为发送长度为零的消息所需的时间。在这种情况下，它将对应于编写调用EDCOX1×0空C+函数的最小Java程序，并计算超过30次测量的经过时间的平均值和STDDEV(做额外的热身调用)。对于在不同的JDK版本和平台上执行相同操作的不同平均结果，您可能会感到惊讶。

只有这样做才能给出使用JNI是否对目标环境有意义的最终答案。

相关讨论