Overhead of a Java JNI call

Question

Possible Duplicate:
What makes JNI calls slow?

First let me say that this questions is born more out of curiosity than real necessity.

I'm curious to know what is the overhead in doing a JNI call from Java, with say, System.arraycopy versus allocating the array and copying the elements over with a for loop.

If the overhead is substantial, then there is probably a rough "magic number" of elements up to which it compensates to simply use a for loop, instead of using the System call. And also, what exactly is involved in the System call that causes this overhead? I'm guessing the stack must be pushed to the context of the call, and that might take a while, but I can't find a good explanation for the whole process.

Let me clarify my question:

I know that using arraycopy is the fastest way to copy an array in Java.

That being said, let's say I'm using it to copy an array of only one element. Since I'm calling the underlying OS to do so, there has to be an overhead in this call. I'm interested in knowing what this overhead is and what happens in the process of the call.

I'm sorry if using arraycopy misled you from the purpose of my question. I'm interested to know the overhead of a JNI call, and what's involved in the actual call.

Mind you, `System` call is a somewhat confusing term as it might be mistaken for a [system call](https://en.wikipedia.org/wiki/System_call). — Fred Foo, Dec 18 '12 at 10:22
By the way, there's a wealth of information in http://stackoverflow.com/questions/2772152/why-is-system-arraycopy-native-in-java — NPE, Dec 18 '12 at 10:24
Deleted my answer, I think this will help you: http://stackoverflow.com/questions/7699020/what-makes-jni-calls-slow — Aviram Segal, Dec 18 '12 at 10:26

NPE · Accepted Answer · 2012-12-18T15:37:19.843

Since I'm calling the underlying OS to do so...

You are right that system calls are fairly expensive. However, the System in System.arraycopy() is a bit of a misnomer. There are no system calls involved.

...there has to be an overhead in this call. I'm interested in knowing what this overhead is and what happens in the process of the call.

When you look at the definition of System.arraycopy(), it's declared as native. This means that the method is implemented in C++. If you were so inclined, you could look at the JDK source code, and find the C++ function. In OpenJDK 7, it's called JVM_ArrayCopy() and lives in hotspot/src/share/vm/prims/jvm.cpp. The implementation is surprisingly complicated, but deep down it's essentially a memcpy().

If arraycopy() is being used as a normal native function, there's overhead to calling it. There's further overhead caused by argument checking etc.

However, it's very likely that the JIT compiler knows about System.arraycopy(). This means that, instead of calling the C++ function, the compiler knows how to generate specially-crafted machine code to carry out the array copy. I don't know about other JVMs, but HotSpot does have such "intrinsic" support for System.arraycopy().

Let's say I'm using it to copy an array of only one element

If your array is tiny, you may be able to beat System.arraycopy() with a hand-crafted loop. You can probably do even better if the size is known at compile time, since then you can also unroll the loop. However, all of that is not really relevant except in the narrowest of circumstances.

+1 The point about inlining a native call is the most important contribution. — Marko Topolnik, Dec 18 '12 at 10:30
Your answer, along with the comment that pointed me towards this: http://stackoverflow.com/questions/7699020/what-makes-jni-calls-slow has been the most helpful, so I'm accepting. Thanks for clearing up some terminology that I didn't put out very clearly. — pcalcao, Dec 18 '12 at 10:32

Evgeniy Dorofeev · Answer 2 · 2012-12-18T11:46:15.890

2

Take a look at java.util.Arrays.copyOf implementations, eg

public static byte[] copyOf(byte[] original, int newLength) {
    byte[] copy = new byte[newLength];
    System.arraycopy(original, 0, copy, 0,
                     Math.min(original.length, newLength));
    return copy;
}

they use System.arraycopy because this is the fastest way.

If you mean whether calling native methods in Java is expensive then take a look at http://www.javamex.com/tutorials/jni/overhead.shtml

UPDATE Question is really interesting, so I've done some testing

        long t0 = System.currentTimeMillis();
        byte[] a = new byte[100];
        byte[] b = new byte[100];
        for(int i = 0; i < 10000000; i++) {
//            for(int j = 0; j < a.length; j++) {
//                a[j] = b[j];
//            }
            System.arraycopy(b, 0, a, 0, a.length);
        }
        System.out.println(System.currentTimeMillis() - t0);

It shows that on very short arrays (< 10) System.arraycopy may be even slower, most probably because it's native, but on bigger arrays it does not matter anymore, System.arraycopy is much faster.

edited Dec 18 '12 at 11:46

answered Dec 18 '12 at 10:26

Evgeniy Dorofeev

133,369
30
199
275

Thanks, upvoted for the link, that was indeed what I was looking for. – pcalcao Dec 18 '12 at 10:35
I've added some tests, see my update – Evgeniy Dorofeev Dec 18 '12 at 10:59
*"... most probably because it's native"* - there are other possible explanations; e.g. because of the book keeping that `arraycopy()` has to do to check the arguments, and select the correct way of doing the copy. – Stephen C Dec 18 '12 at 14:12
Right, "...because it's native" does not seem as a good explanation, I actually meant all those things people say about jni overhead... – Evgeniy Dorofeev Dec 18 '12 at 14:17

score 1 · Answer 3 · answered Dec 18 '12 at 10:51

I'm interested to know the overhead of a JNI call, and what's involved in the actual call.

The System.arraycopy() method is rather complicated^* and it is unlikely that the JIT compiler inlines it (as one of the other answers suggests).

On the other hand, it is likely the JIT compiler uses an optimized calling sequence, since this is an intrinsic native method. In other words, this is most likely not a normal JNI call.

^{* - System.arraycopy is not a simple memory copy. It has to test its arguments to avoid reading or writing beyond the array bounds, and so on. And in the case when you are copying from one object array to another it may need to check that actual type of each objects copied. All of this adds up to far more code than it is sensible to inline.}

score 0 · Answer 4 · answered Dec 18 '12 at 10:23

0

You have it the wrong way around. System.arraycopy() is a super fast native implementation provided by the JVM

There is no "overhead" - there is only "advantage"

answered Dec 18 '12 at 10:23

Bohemian

412,405
93
575
722

Overhead of a Java JNI call

4 Answers4