FastNative
public
abstract
@interface
FastNative
implements
Annotation
| dalvik.annotation.optimization.FastNative |
An ART runtime built-in optimization for native methods to speed up JNI transitions:
Compared to normal native methods, native methods that are annotated with
@FastNative use faster JNI transitions from managed code to the native code
and back. Calls from a @FastNative method implementation to JNI functions
that access the managed heap or call managed code also have faster internal transitions.
While executing a @FastNative method, the garbage collection cannot
suspend the thread for essential work and may become blocked. Use with caution. Do not use
this annotation for long-running methods, including usually-fast, but generally unbounded,
methods. In particular, the code should not perform significant I/O operations or acquire
native locks that can be held for a long time. (Some logging or native allocations, which
internally acquire native locks for a short time, are generally OK. However, as the cost
of several such operations adds up, the @FastNative performance gain
can become insignificant and overshadowed by potential GC delays.)
Acquiring managed locks is OK as it internally allows thread suspension.
For performance critical methods that need this annotation, it is strongly recommended
to explicitly register the method(s) with JNI RegisterNatives instead of relying
on the built-in dynamic JNI linking.
The @FastNative optimization was implemented for system use since
Android 8 and became CTS-tested public API in Android 14. Developers aiming for maximum
compatibility should avoid calling @FastNative methods on Android 13-.
The optimization is likely to work also on Android 8-13 devices (after all, it was used
in the system, albeit without the strong CTS guarantees), especially those that use
unmodified versions of ART, such as Android 12+ devices with the official ART Module.
The built-in dynamic JNI linking is working only in Android 12+, the explicit registration
with JNI RegisterNatives is strictly required for running on Android versions 8-11.
The annotation is ignored on Android 7-.
Deadlock Warning: As a rule of thumb, any native locks acquired in a
@FastNative call (despite the above warning that this is an unbounded
operation that can block GC for a long time) must be released before returning to managed code.
Say some code does:
fast_jni_call_to_grab_a_lock();
does_some_java_work();
fast_jni_call_to_release_a_lock();
This code can lead to deadlocks. Say thread 1 just finishes
fast_jni_call_to_grab_a_lock() and is in does_some_java_work().
GC kicks in and suspends thread 1. Thread 2 now is in fast_jni_call_to_grab_a_lock()
but is blocked on grabbing the native lock since it's held by thread 1.
Now thread suspension can't finish since thread 2 can't be suspended since it's doing
FastNative JNI.
Normal JNI doesn't have the issue since once it's in native code, it is considered suspended from java's point of view. FastNative JNI however doesn't do the state transition done by JNI.
Note that even in FastNative methods you are allowed to allocate objects and make upcalls into Java code. A call from Java to a FastNative function and back to Java is equivalent to a call from one Java method to another. What's forbidden in a FastNative method is blocking the calling thread in some non-Java code and thereby preventing the thread from responding to requests from the garbage collector to enter the suspended state.
Has no effect when used with non-native methods.
Summary
Inherited methods | |
|---|---|