Overhead of a Java JNI call [duplicate]

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.

Answer 1

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.

Answer 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.