将C字符串数组移动到Java空间的更有效方法

Question

Let's say I have an array of C strings with N elements. My goal is to pass that array into a Java function using the JNI and return a new string array of equal length back to C space. At present I am doing the following:

• Using NewObjectArray to generate a Java Object array of length N.
• Calling NewStringUTF/SetObjectArray N times, to box each individual C string into the Java Object array.
• Invoking copyStrArr (source below).
• Allocating a length N array of (char *) with malloc.
• Calling GetObjectArrayElement/GetStringUTFChars N times, to unbox each individual Java String from the returned Java Object array.

For reference, the Java code looks like this:

public static String[] copyStrArr(String []inArr)
{
    String []outArr = new String[inArr.length];
    for(int _i = 0; _i < outArr.length; _i++) {
        outArr[_i] = inArr[_i]; /* Normally real work would be done here */
    }
    return outArr;
}

In the "real" case actual work would be done inside the for loop, but for benchmarking we're just making a copy of the data.

For large values of N this is slow. Ungodly slow. When moving a similarly sized array of ints or doubles from C to Java and back it runs ~70x faster than the String[] case. about 99.5% of the time is spent boxing and unboxing the data. In the primitive case the JNI offers {Set,Get}ArrayRegion functions to batch copy primitive arrays from C space to Java space and back, which is much faster.

It has been suggested I use a byte[] as an intermediary to get the data into Java space, and then do the individual String Object boxing in Java (where the JVM can optimize things). Benchmarks have shown that this performs slightly worse than the original test, moving much of the overhead into Java. Part of this might be that I may not be optimally unboxing/boxing the byte[] in Java. I am doing the following:

• Allocating a sufficiently large byte[] with NewByteArray
• Calling SetByteArrayRegion N times to populate the byte[]
• Invoking copyBytArray (source below)
• Calling GetByteArrayRegion and copying the whole result back into C space
• Allocating a sufficiently large array of (char *)
• Copying each of the N Strings out of the result into the newly allocated array.

My Java code looks like this:

public static byte[] copyBytArr(byte []inArr)
{
    String[] tokInArr = new String(inArr, UTF8_CHARSET).split("\0");
    String []tokOutArr = new String[tokInArr.length];
    int len = 0;
    for(int _i = 0; _i < tokOutArr.length; _i++) {
        tokOutArr[_i] = tokInArr[_i]; /* Normally real work would be done here */
        len += (tokInArr[_i].length() + 1);
    }
    byte[] outArr = new byte[len];
    int _j = 0;
    for(int _i = 0; _i < tokOutArr.length; _i++) {
        byte[] bytes = tokOutArr[_i].getBytes(UTF8_CHARSET);
        for(int _k = 0; _k < bytes.length; _k++) {
            outArr[_j++] = bytes[_k];
        }
        outArr[_j++] = '\0';
    }
    return outArr;
}

In this test about 55% of the overhead was spent in Java, and the rest was spent boxing/unboxing.

It has been suggested that some of my overhead is related to the fact that I an using UTF-8 data in C, since Java uses UTF-16. This is unavoidable.

Does anyone have any ideas about how I might go about this more efficiently?

Answer 1

I think your problem is allocation of many string objects. In order to get real performance you need to just interchange large byte[] and use Wrapper Classes "pointing" to the byte array for String processing. As long you are creating String Objects from C chars[] back and forth, you won't get real throughput.

FST is doing something similar with the "StructString" class to operate on byte[] data without the need to create "real" Objects.

To speed up dataexchange further you might want to create shared memory using memory mapped files and access this via Unsafe or ByteBuffers.