0

I'm reading the article here: http://www.kdgregory.com/?page=java.byteBuffer

On that page, there is this section:

In fact, the only reason that I can see for using direct buffers in a pure Java program is that they won't be moved during garbage collection. If you've read my article on reference objects, you'll remember that the garbage collector compacts the heap after disposing of dead objects. If you have large blocks of heap memory allocated as buffers, they may get moved as part of compaction, and no matter how fast your CPU, that takes time; it's not something you want to do on every full collection. Since the direct buffer lives outside of the heap, it isn't affected by collections. On the other hand, every data access is a JNI call. Only benchmarking will tell you whether this helps or hurts your particular application.

The JNI statement implies there is a drawback to using JNI, but I'm unsure what it is. Can anyone help? I did find this question on stack overflow: Disadvantages of using Java Native Interface

However, I didn't believe from the context of the statement in that paragraph the author implied that the drawback was that JNI was difficult to debug or that it could take down the jvm. Thanks!

Community
  • 1
  • 1
soeske18
  • 115
  • 1
  • 6
  • This kind of seems like begging the question. Considering how ludicrously low-level JNI is, I'd doubt the overhead is all that significant. I.e. you're not marshalling complex types or anything. – millimoose Dec 24 '13 at 00:13
  • 1
    That said: [What makes JNI calls slow?](http://stackoverflow.com/questions/7699020/what-makes-jni-calls-slow) – millimoose Dec 24 '13 at 00:15
  • 1
    KD Gregory doesn't understand what direct buffers are for. They are for use when copying between channels, when you don't actually need the data in the Java code at all. They *save* JNI-style operations, by not moving the data between the JNI side and the JVM side. If you're manipulating the data in Java, of course they are pointless and costly. – user207421 Dec 24 '13 at 01:34
  • I don't think the quote is accurate. Accessing direct buffers is about as fast as arrays. There is no "call" to a native function. Just a possible bounds check and a memory access. – Aleksandr Dubinsky Dec 24 '13 at 01:57
  • @AleksandrDubinsky Impossible. The buffer is in JNI space, not in JVM space. There has to be a JNI call. That is the whole point of direct buffers. – user207421 Jan 02 '14 at 00:17
  • @EJP Why impossible? To the JVM, since it is a native process, there is really only one memory space. A direct ByteBuffer is a way for Java code to access any address in that memory space, instead of just what is on the heap. It compiles down to essentially the same machine instructions as other memory accesses. ByteBuffers are meant to be fast. The designers didn't even want to put a conditional in `get` and `put` that checks whether a MappedByteBuffer has been unmapped, which is why you can't unmap it. (Despite the crippling bugs this causes.) – Aleksandr Dubinsky Jan 02 '14 at 00:38

1 Answers1

0

JNI depends on your application. Sometime you will use the third-part c library. Ant the library may be is not full tested. It will contain bugs of memory leak or invalid memory accessing. There two problems are big issuses of JNI. It will make your application crashed.

you can write a simple library in c like:

int * a = NULL;
*a = 20;

and call the code in JAVA. Your JAVA application will down without JVM output, and you can not catch any exception in JAVA.

user918888
  • 151
  • 1
  • 7