是什么让 JNI 调用变慢? [英] What makes JNI calls slow?

问题描述

我知道在 Java 中进行 JNI 调用时越界"很慢.

I know that 'crossing boundaries' when making a JNI call in Java is slow.

但是我想知道是什么使它变慢?进行 JNI 调用时，底层 jvm 实现会做什么，使其变得如此缓慢?

However I want to know what is it that makes it slow? What does the underlying jvm implementation do when making a JNI call that makes it so slow?

推荐答案

首先，值得注意的是，慢"，我们正在谈论可能需要几十纳秒的东西.对于微不足道的本机方法，2010 年，我在 Windows 桌面上测量了平均 40 ns 的调用时间，在我的 Mac 桌面上测量了 11 ns 的调用时间.除非您拨打多次电话，否则您不会注意到.

First, it's worth noting that by "slow," we're talking about something that can take tens of nanoseconds. For trivial native methods, in 2010 I measured calls at an average 40 ns on my Windows desktop, and 11 ns on my Mac desktop. Unless you're making many calls, you're not going to notice.

也就是说，调用本机方法可能比调用普通 Java 方法慢.原因包括:

That said, calling a native method can be slower than making a normal Java method call. Causes include:

• 本地方法不会被 JVM 内联.它们也不会针对这台特定机器进行即时编译——它们已经被编译了.
• 可以复制 Java 数组以在本机代码中访问，然后再复制回来.成本可以与阵列的大小成线性关系.我测量了 JNI复制一个 100,000 数组的平均值，在我的 Windows 桌面上平均约为 75 微秒，在 Mac 上为 82 微秒.幸运的是，可以通过 GetPrimitiveArrayCritical 获得直接访问 或 NewDirectByteBuffer.
• 如果该方法传递了一个对象，或者需要进行回调，则本机方法可能会自行调用 JVM.从本机代码访问 Java 字段、方法和类型需要类似于反射的东西.签名在字符串中指定并从 JVM 查询.这既缓慢而且容易出错.
• Java 字符串是对象，有长度并经过编码.访问或创建字符串可能需要 O(n) 副本.

• Native methods will not be inlined by the JVM. Nor will they be just-in-time compiled for this specific machine -- they're already compiled.
• A Java array may be copied for access in native code, and later copied back. The cost can be linear in the size of the array. I measured JNI copying of a 100,000 array to average about 75 microseconds on my Windows desktop, and 82 microseconds on Mac. Fortunately, direct access may be obtained via GetPrimitiveArrayCritical or NewDirectByteBuffer.
• If the method is passed an object, or needs to make a callback, then the native method will likely be making its own calls to the JVM. Accessing Java fields, methods and types from the native code requires something similar to reflection. Signatures are specified in strings and queried from the JVM. This is both slow and error-prone.
• Java Strings are objects, have length and are encoded. Accessing or creating a string may require an O(n) copy.

在Java(tm) Platform Performance: Strategies and Tactics"，2000 年，Steve Wilson 和 Jeff Kesselman 合着的9.2:检查 JNI 成本"部分中可以找到一些可能已经过时的其他讨论.这是大约三分之一的路这个页面，在下面@Philip 的评论中提供.

Some additional discussion, possibly dated, can be found in "Java(tm) Platform Performance: Strategies and Tactics", 2000, by Steve Wilson and Jeff Kesselman, in section "9.2: Examining JNI costs". It's about a third of the way down this page, provided in the comment by @Philip below.

2009 年 IBM developerWorks 论文 使用 Java 本机接口的最佳实践"; 提供了一些避免 JNI 性能缺陷的建议.

The 2009 IBM developerWorks paper "Best practices for using the Java Native Interface" provides some suggestions on avoiding performance pitfalls with JNI.

这篇关于是什么让 JNI 调用变慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！