Is the native method expensive? JNI "Secret" extension

Why do Java programmers use native methods? Sometimes, to use a third-party DLL library. In other cases, to speed up the critical algorithm due to optimized C code or assembler. For example, for streaming media processing, compression, encryption, etc.

But the call to the native method is not free. At times, the overhead of JNI is even greater than the performance gain. And all because they include:

1. create stack frame;
2. shifting arguments in accordance with the ABI ;
3. wrapping links in JNI handles ( jobject );
4. passing additional arguments JNIEnv* and jclass ;
5. capture and release of a monitor if the method is synchronized ;
6. "Lazy" linking of native function;
7. tracing method input and output;
8. transfer of a stream from in_Java to in_native and back;
9. checking the need for a safepoint;
10. handling possible exceptions.

But often the native methods are simple: they do not throw exceptions, do not create new objects in the heap, do not bypass the stack, do not work with handles, and are not synchronized. Is it possible for them not to do unnecessary actions?

Yes, and today I will talk about the undocumented features of HotSpot JVM for the accelerated call of simple JNI methods. Although this optimization has appeared since the first versions of Java 7, which is surprising, no one has ever written about it.

Jni how we know it

For example, consider a simple native method that takes an array of byte[] as input and returns the sum of elements. There are several ways to work with an array in JNI:

• GetByteArrayRegion - copies the elements of the Java array into the specified place in the native memory;
  
  GetByteArrayRegion Example

   JNIEXPORT jint JNICALL Java_bench_Natives_arrayRegionImpl(JNIEnv* env, jclass cls, jbyteArray array) { static jbyte buf[1048576]; jint length = (*env)->GetArrayLength(env, array); (*env)->GetByteArrayRegion(env, array, 0, length, buf); return sum(buf, length); } 

  
  
• GetByteArrayElements is the same, only the JVM itself allocates the memory where the elements will be copied. When you finish working with an array, you must call ReleaseByteArrayElements.
  
  GetByteArrayElements Example

   JNIEXPORT jint JNICALL Java_bench_Natives_arrayElementsImpl(JNIEnv* env, jclass cls, jbyteArray array) { jboolean isCopy; jint length = (*env)->GetArrayLength(env, array); jbyte* buf = (*env)->GetByteArrayElements(env, array, &isCopy); jint result = sum(buf, length); (*env)->ReleaseByteArrayElements(env, array, buf, JNI_ABORT); return result; } 

  
  
• Why, you ask, make a copy of the array? But you can't work with objects in the Java Heap directly from the native, since they can be moved by the garbage collector right while the JNI method is running. However, there is a function GetPrimitiveArrayCritical , which returns the direct address of the array in the heap, but at the same time prohibits the operation of the GC before calling ReleasePrimitiveArrayCritical .
  
  GetPrimitiveArrayCritical Example

   JNIEXPORT jint JNICALL Java_bench_Natives_arrayElementsCriticalImpl(JNIEnv* env, jclass cls, jbyteArray array) { jboolean isCopy; jint length = (*env)->GetArrayLength(env, array); jbyte* buf = (jbyte*) (*env)->GetPrimitiveArrayCritical(env, array, &isCopy); jint result = sum(buf, length); (*env)->ReleasePrimitiveArrayCritical(env, array, buf, JNI_ABORT); return result; } 

  
  

Critical native

And here is our secret tool. Outwardly, it is similar to the usual JNI method, only with the JavaCritical_ prefix instead of Java_ . There are no JNIEnv* and jclass , and instead of jbyteArray two arguments are passed: jint length - the length of the array and jbyte* data - a “raw” pointer to the elements of the array. Thus, the Critical Native method does not need to call the expensive JNI functions GetArrayLength and GetByteArrayElements - you can immediately work with an array. At the time of such a method, the GC will be delayed.
')

 JNIEXPORT jint JNICALL JavaCritical_bench_Natives_javaCriticalImpl(jint length, jbyte* buf) { return sum(buf, length); } 

As you can see, in the implementation there is nothing extra.
But in order for a method to become Critical Native, it must satisfy strict limitations:

• The method must be static and not synchronized ;
• among the arguments, only primitive types and primitive arrays are supported;
• Critical Native cannot call JNI functions and, therefore, allocate Java objects or throw exceptions;
• and, most importantly, the method should be completed in a short time , since it blocks the GC for the execution time.

Critical Natives was conceived as a private API of Hotspot for the JDK in order to speed up the call to the cryptographic functions implemented in the native. The maximum that can be found from the description is comments to the task in the bugtracker . Important feature: JavaCritical_ functions are called only from hot (compiled) code, therefore, in addition to the JavaCritical_ implementation, the method must also have a “spare” traditional JNI implementation. However, for compatibility with other JVM it is even better.

How many will be in grams?

Let's measure what the savings are on arrays of different lengths: 16, 256, 4KB, 64KB and 1MB. Naturally, using JMH .


It turns out that for small arrays the cost of a JNI call is many times greater than the time of the method itself! For arrays of hundreds of bytes, the overhead is comparable to useful work. Well, for multi-kilo byte arrays the method of calling is not so important - all the time is spent on processing itself.

findings

Critical Natives is a private JNI extension in HotSpot, which appeared with JDK 7. By implementing a JNI-like function according to certain rules, you can significantly reduce the overhead of calling the native method and processing Java arrays in native code. However, for long-playing functions such a solution is not suitable, since the GC will not be able to start until Critical Native is executed.