JNIWrapper Now on Mac OS X 64-bit

Question: can you pass Java memory to a native library without the memory copied to and from the native code, and instead use the "pinning" feature? That way it could make sense to write high performance large volume array calculations in native code. With JNI you can do that. The memory is "pinned" for the duration of the call. I've looked at JNA quite a while ago, and found that pinning wasn't an option. Does JNIWrapper let you do this?

Hi Jose, how about native image processing on BufferedImages. Some of them part of an off screen cache. The kind of magic I can pull off using beautiful raw machine code, I can't in Java. Allocating native memory for these things might create a massive memory management problem. I found pinning worked perfectly in pure JNI, without any noticable performance penalty. Copying memory for every call, would make the machine code writing efforts much less attractive.

Currently JNIWrapper doesn't have “Pinning” feature. The main reason why it is not supported now is that such feature has quite restricted usage. 'Pinning' feature is useful when you need to pass a large amount of memory from Java to native side without copying it. And actually "pinning" is just a new word for passing the data to a function call via pointer.

The main drawback there is that it is useful only if memory structures on Java and native sides are equal. For example, it is useful when you are passing an array of bytes, shorts, ints or longs. Unlike .NET, Java does not allow combining primitive types into the complex structures, because Java does not have an analogue of .NET's 'structure' keyword. So, if your Java arrays contains structures instead of primitive types then you will have to copy data from Java to native memory anyway.

On the other side, for now we do not have any requests for increasing the performance of JNIWrapper in terms of passing large amount of memory into a native side and back. Moreover, the performance of working with native API is very fast. For example, our JxCapture API performes creating of screenshots as fast as a C application, which is even faster than Robot API. And all that is made using just regular function calls.

If your application has a performance bottleneck in this action, we of course can look at how we can help you from our side, and possibly add pinning feature into JNIWrapper.

No.

Mike wants to work with the same piece of "real" memory in Java and in native, the critical section feature of JNI allows to access the native memory *behind* the Java memory (in this case a primitive array), this way there is no copy between Java memory and native memory. If you work ever with native memory there is no problem, this memory can be accesed from Java using a buffer (a Java-native wrapper), one single piece of memory is used. Mike's problem is Mike wants one single piece of memory managed as a normal Java data byte array. Isn't it Mike?

 

But then you have to allocate memory in Java in a special way, with nio buffers.

Ordinary BufferedImages are allocated the normal way, and the native code needs to have access to that to play with pixels...