Comments on: Efficient JNI programming, part I

By: This note’s for you » Blog Archive » Efficient JNI programming IV: Wrapping native data objects

Mon, 30 Jul 2007 20:59:55 +0000

[…] check out part I, part II and part III of this series too. Blog this:Digg […]

By: This note’s for you » Blog Archive » Efficient JNI programming III: Array access

Fri, 27 Jul 2007 22:18:29 +0000

[…] last two parts of this small series dealt with considerations when to implement stuff in a native JNI method and how to best implement field and method access in JNI. Now I will take a close look at another […]

By: This note’s for you » Blog Archive » Efficient JNI programming II: Field and method access

Tue, 24 Jul 2007 19:31:36 +0000

[…] This note’s for you Just another WordPress weblog « Efficient JNI programming, part I […]

By: roman

roman — Mon, 23 Jul 2007 13:39:15 +0000

I wouldn’t over-emphasize the ‘overhead of a JNI call’. Granted, some VMs aren’t really smart with this. On the other hand, many VMs are really damn smart and have no overhead for JNI calls at all. A good JIT for example would inline all the calling stuff into the generated machine code and makes a JNI call exactly as fast as any native function call. Even the less optimized VMs that I know aren’t that bad in this regard. I think this is mostly a myth that stems from the other problems with JNI (field access, method access and array access).

By: Wayne Meissner

Wayne Meissner — Mon, 23 Jul 2007 11:14:12 +0000

Well, you now have more fodder for a “performance myths and fallacies” section

Should be interesting if you benchmark the different use-cases, and the different ways of sending data (primitive vs object with JNI access, etc)

Of course, I suspect that any differences are largely washed away due to the overhead of a JNI call.

By: roman

roman — Mon, 23 Jul 2007 09:54:27 +0000

Wayne, thank you for your comments. I’d like to add my notes:

re 2) I don’t think it’s as easy as that. I doubt that JNI is optimized specifically for this. With JNI you can pass objects just as easily to JNI code as primitives, and it makes no difference (runtime-performance-wise) if you access a field in Java or in JNI. However, it’s harder to do in JNI and easier to shoot in your foot (I’ll discuss that in part II).

re 3) I don’t agree here either. All in all there are 3 or 4 different ways to implement bulk data transfer, each of them has their advantages and disadvantages. None of them is the one perfect solution for all cases (for example, accessing ByteBuffers in Java is relatively slow, compared to Java arrays). It depends a lot on the actual scenario which way to choose. I’ll discuss that in part III of this mini series.

By: Wayne Meissner

Wayne Meissner — Mon, 23 Jul 2007 03:31:56 +0000

Andrew Cowie covered a bit of JNI performance stuff in his LCA2007 talk as well. Basically, it boils down to:

1) Do as much work on the other side of the boundary per boundary crossing as possible. Like you said, if you’re going to do a loop that calls a native function, then do it on the native side rather than in java. This reduces the overhead of JNI calls.

2) Whenever possible, pass primitives (int, long, etc) down to JNI rather than classes. JNI is optimised to handle these, plus it avoids calling back into java to pull out fields from a class.

3) If you’re going to transfer bulk data from JNI to java, use direct ByteBuffers. Not all arches seem to support pinning of primitive arrays.

For cases 1 + 2 (gaining access to existing libraries/native resources), use one of the JNI wrapper libraries like JNA or nlink - they allow you to avoid writing any JNI code at all.