I have a question abour memory management of java port of OpenCV.
JNIEXPORT jlong JNICALL Java_org_opencv_core_Mat_n_1Mat__III
(JNIEnv* env, jclass, jint rows, jint cols, jint type)
{
try {
LOGD("Mat::n_1Mat__III()");
Mat* _retval_ = new Mat( rows, cols, type );
return (jlong) _retval_;
} catch(cv::Exception e) {
LOGD("Mat::n_1Mat__III() catched cv::Exception: %s", e.what());
jclass je = env->FindClass("org/opencv/core/CvException");
if(!je) je = env->FindClass("java/lang/Exception");
env->ThrowNew(je, e.what());
return 0;
} catch (...) {
LOGD("Mat::n_1Mat__III() catched unknown exception (...)");
jclass je = env->FindClass("java/lang/Exception");
env->ThrowNew(je, "Unknown exception in JNI code {Mat::n_1Mat__III()}");
return 0;
}
}
This code block is taken from '..\OpenCV-2.4.5\modules\java\generator\src\cpp\Mat.cpp'. My question is about following part:
Mat* _retval_ = new Mat( rows, cols, type );
return (jlong) _retval_;
It returns mat objects address by casting it to jlong and does not delete the object. So, how does the memory management is done? Does java runs Garbage Collector? Or are there any other code in C++ side that clears the memory somehow?
There is no memory manage done here.
The function really returns a pointer to a heap-allocated object without caring about the memory management.
Actually this method correspond to the Java class org.opencv.core.Mat which has a long attribute named nativeObj. So this java class is managing a pointer and it is always passed to the underlying C++ implementation.
On the Java Mat object, you have to call the release method, which in turn call the JNI function Java_org_opencv_core_Mat_n_release.
The finalize method also call n_delete which free the memory.
You can see the Java code here.
Well, I couldn't find the answer but I did a little trick. I defined a member variable as;
cv::Mat* mat = nullptr;
And when I need to allocate memory for a new Mat object first I run the following code and then do the memory allocation.
if(mat != nullptr) // this is satisfied if memory is already allocated and not deleted
{
delete mat;
mat = nullptr;
}
mat = new cv::Mat(rows, cols, type);
return (jlong)mat;
But I'm still loking forward to learn, how does OpenCV overcomes this problem.
Related
My JNI library works flawlessly on Windows, however, on Linux I always get a strange segmentation fault.
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000
The stack crace from the crash file is this:
C [libfmodjavaL.so+0xfb8c] JNIEnv_::GetStaticObjectField(_jclass*, _jfieldID*)+0x18
C [libfmodjavaL.so+0xf72b] Logger::sendToSystemOut(bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)+0x75
C [libfmodjavaL.so+0xf7c2] Logger::log(char const*)+0x4c
C [libfmodjavaL.so+0xd70d] fmodDebugCallback(unsigned int, char const*, int, char const*, char const*)+0x127
So it appears that it crashed when calling GetStaticObject field in the Logger class. This is that method:
void Logger::sendToSystemOut(bool error, std::string message) {
JNIEnv* jni = FMODWrapper::utils->getJNI();
jobject printStream;
if (error) {
printStream = jni->GetStaticObjectField(this->systemClass, this->errFieldID);
} else {
printStream = jni->GetStaticObjectField(this->systemClass, this->outFieldID);
}
jobject messageString = jni->NewStringUTF(message.c_str());
jni->CallObjectMethod(printStream, this->printlnMethodID, messageString);
}
So I'm guessing something's not right about storing the class and field IDs of these fields. But the weird thing is, I get logging output when my library starts up, even from FMOD, which the fmodDebugCallback gets called by.
Logger::Logger(const char* name) {
this->name = name;
JNIEnv* jni = FMODWrapper::utils->getJNI();
this->systemClass = FMODWrapper::utils->findClass("java/lang/System");
this->outFieldID = jni->GetStaticFieldID(this->systemClass, "out", "Ljava/io/PrintStream;");
this->errFieldID = jni->GetStaticFieldID(this->systemClass, "err", "Ljava/io/PrintStream;");
jclass printStreamClass = FMODWrapper::utils->findClass("java/io/PrintStream");
this->printlnMethodID = jni->GetMethodID(printStreamClass, "println", "(Ljava/lang/String;)V");
}
So, logging works flawlessly on Windows, but after some time crashes on Linux. Compiled with g++ on Fedora 29 64-bit.
Update: my method for getting a JNIEnv*
JNIEnv* Utils::getJNI() {
JNIEnv* jni;
int getEnvResult = FMODWrapper::jvm->GetEnv((void**) &jni, JNI_VERSION_1_6);
if (getEnvResult == JNI_EDETACHED) {
FMODWrapper::jvm->AttachCurrentThread(ANDROID_VOIDPP_CAST &jni, nullptr);
}
return jni;
}
Update 2: the code itself works up to a certain point since I'm getting log messages. Might be something to do with threads?
https://hastebin.com/kuzefuwawu.txt
systemClass, errFieldId, and outFieldID are all obtained from a different JNIEnv.
The JNIEnv cannot be cached:
Keeping a global reference to the JNIEnv environment
Just as it cannot be cached, you cannot store ids that were obtained from the other JNIEnv that you should no longer be using, nor should you be using anything that came from it. You need to get them all from the current valid JNIEnv.
The problem is not with thread affinity of class references or field IDs. The problem is with using a local class reference out of its scope. This is an implementation detail of some JVMs, that local references do not actually expire.
The fix would be to use
Logger::Logger(const char* name) {
this->name = name;
JNIEnv* jni = FMODWrapper::utils->getJNI();
this->systemClass = jni->NewGlobalRef(jni->findClass("java/lang/System"));
…
I have an Android app that employs both React Native and JNI. C++ (via a fork of the JUCE library) is used to generate one of the views.
React Native requires that a new instance of a view be returned from the overridden method createViewInstance(context). This seems to get called each time a React Native component containing this view is updated.
Here is my (simplified) implementation:
protected JuceViewHolder createViewInstance(ThemedReactContext themedReactContext) {
JuceBridge juceBridge = JuceBridge.getInstance();
juceViewHolder = new JuceViewHolder(themedReactContext);
// JNI method: this will trigger JuceBridge.createNewView
MainActivity.createJuceWindow(juceViewHolder);
return juceViewHolder;
}
For reference, createJuceWindow is defined as:
JUCE_JNI_CALLBACK (JUCE_ANDROID_ACTIVITY_CLASSNAME, createJuceWindow, jobject, (JNIEnv* env, jclass, jobject view))
{
JuceView::getInstance().createJuceWindow(view);
}
which calls:
void createJuceWindow(jobject view)
{
viewToAttachTo = GlobalRef(view); // [GlobalRef][1] manages NewGlobalRef
myComponent = std::unique_ptr<MyComponent> (new MyComponent);
myComponent->setVisible (true);
myComponent->setOpaque(true);
if (viewToAttachTo.get() == nullptr)
DBG ("createJuceWindow: viewToAttachTo null!!!");
myComponent->setBounds(Desktop::getInstance().getDisplays().getMainDisplay().userArea);
myComponent->addToDesktop (0, viewToAttachTo.get()); // This passes in the `jobject` held by GlobalRef
}
I have separated the JuceViewHolder derived from ViewGroup, and I am passing it to a C++ function via JNI in order to attach the (Java)ComponentPeerView generated from the (C++) AndroidComponentPeer constructor
AndroidComponentPeer (Component& comp, const int windowStyleFlags, void* viewToAttachTo)
: ComponentPeer (comp, windowStyleFlags),
usingAndroidGraphics (false),
fullScreen (false),
sizeAllocated (0),
scale ((float) Desktop::getInstance().getDisplays().getMainDisplay().scale)
{
// NB: must not put this in the initialiser list, as it invokes a callback,
// which will fail if the peer is only half-constructed.
if (viewToAttachTo == nullptr) DBG ("viewToAttachTo null");
view = GlobalRef (android.bridge.callObjectMethod (JuceBridge.createNewView,
(jboolean) component.isOpaque(),
(jlong) this,
(jobject) viewToAttachTo));
if (view.get() == nullptr)
DBG ("view null!");
else
DBG ("got view.");
if (isFocused())
handleFocusGain();
}
via the createNewView method: (simplified here)
public final ComponentPeerView createNewView (boolean opaque, long host, ViewGroup viewToAttachTo)
{
ComponentPeerView v = new ComponentPeerView (viewToAttachTo.getContext(), opaque, host);
viewToAttachTo.addView(v);
return v;
}
host is a pointer to the C++ AndroidComponentPeer instance.
This works initially, however it seems that if I switch to another View or Activity and/or switch back to the C++ View, I get a crash similar to the following:
JNI ERROR (app bug): accessed deleted global reference 0x100566
art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: use of deleted global reference 0x100566
art/runtime/java_vm_ext.cc:410] from void com.juce.JuceBridge$ComponentPeerView.focusChanged(long, boolean)
My current assumption is that the error is due to the void* pointer becoming obsolete at some point due to the garbage collector moving the underlying object, as described in this article. What I got from the article is that jobject should be used in place of a pointer.
However the method signature of the Component::addToDesktop method that I have employed uses void*:
virtual void addToDesktop (int windowStyleFlags,
void* nativeWindowToAttachTo = nullptr);
(This is the method used in iOS to pass a native UIView to attach a Component to)
Is my assumption valid? If so, is it possible to safely cast a void* pointer to a Java object, store it as a jobject (via NewGlobalRef) and then pass it back to Java?
I have a problem in my Java native audio library but first, here is my current approach:
With a native method I'm opening a 'global' stream, which receives data over a callback function.
The callback function runs until there is no data.
If there is no data, the stream only stops, but does not get closed.
Now I wanted to feed the stream with data again [trying to start stream again(this operation is allowed)], but the stream has already been deleted.
So now I tried to figure out how to prevent deletion of the stream from C++ or Java.
One solution was to create a thread in the stream, which prevents the deletion.
But I don't like this solution...
So I searched how to keep such objects alive and found out, that there are so called "global references" which can be made with the JNI. But I did not understand whether they are only for java objects or for both.
Also I tried out whether another pointer type of C++ could help.
I appreciate any help or ideas, it does not have to be JNI only. C++ standard library methods/functions/classes etc. are also good :) !
System information:
Compiler: MinGW64 over MSYS2
JDK8u91
Of course 64bit operation system (Does not have to be named xD)
With global stream is meant, that the stream is accessible to all JNI methods.
EDIT:
Okay, 'to let the cat out of the back' I'm using RtAudio.
Realtime C++ Audio Library
Example:
//THIS IS C++ CODE
RtAudio audio(RtAudio::WASAPI);
int callback(//Buffer stuff etc.){
//do something
if(data.isEmpty())return 1;//invokes audio.closeStream() but this does NOT closes the stream!
else return 0; //Go on with the stream rather wait for the next call
}
JNIEXPORT void JNICALL openStream(jintArray data){
//This is a outputstream
audio.openStream(&outputParams,....., &callback,....);
audio.startStream();
}
JNIEXPORT void JNICALL fillData(jintArray data){
//filldata again!
stream.start(); //Starts the stream but does nothing, because the stream is deleted because of Java
}
If I would change the openStream method to this, the stream won't be deleted but I look for a better solution...
JNIEXPORT void JNICALL openStream(jintArray data){
//This is a outputstream
audio.openStream(&outputParams,....., &callback,....);
audio.startStream();
**while(true); //ADD THIS AND THE STREAM WON'T BE DELETED!**
}
Another solution is to add into the RtAudio API a "keepInstanceAliveThread" which is called after the stopStream() method and deleted after calling startStream() or closeStream(). I would rather prefer another solution but at all, there isn't any yet.
Pre-outcomes:
Thanks to #marcinj:
global object are known to cause many problems, its hard to control their construction/destruction.
EDIT:
I found out in the internet (also on stackoverflow), that the destructor is called after the return of a JNI method.
Use a long in the Java object to hold a pointer to the C++ object.
A Java long is 64 bits, and every platform Java runs on has either 32- or 64-bit pointers. And every platform Java is supplied for will support this, despite it not being strictly-conforming C or C++ code.
Java:
// class member
private long audio
// native functions
private native long openStream( int[] data );
private native void deleteStream( long audio );
private native void nativeFillData( long audio, int[] data );
public MyClass()
{
audio = openStream( data );
}
public void fillData( int[] data )
{
nativeFillData( this.audio, data );
}
// delete the C++ object - you may want to
// control this directly and not rely on
// finalize() getting called
protected void finalize()
{
deleteStream( audio );
super.finalize();
}
C++:
JNIEXPORT jlong JNICALL openStream(jintArray data)
{
RtAudio *audio = new RtAudio(RtAudio::WASAPI);
audio->openStream(&outputParams,....., &callback,....);
audio->startStream();
// C-style cast - JNI interface is C, not C++
return( ( jlong ) audio );
}
JNIEXPORT void JNICALL deleteStream(jlong jaudio)
{
RtAudio *audio = static_cast <RtAudio *>( jaudio );
delete audio;
}
JNIEXPORT void JNICALL nativeFillData(jlong jaudio, jintArray data)
{
RtAudio *audio = static_cast <RtAudio *>( jaudio );
audio->start();
...
}
1) JAVA THREAD WAY
We can create a new thread to keep running in a JNI function locked with a monitor or conditional while loop.
Then a separate call would stop the execution of the thread in your function by releasing the monitor or changing the condition in the while loop.
2) JAVA OBJECT REFERENCE WAY
Another option is to create a Global Reference of your object
Android JNI and NewGlobalRef.
Here a separate call on USB disconnect would do DeleteGlobalRef.
We can also move the life cycle of your C++ object into java by passing it back to the java layer
keep some sort of c++ object alive over multiple jni calls.
Here a separate call on USB disconnect would remove any reference to C++ object in your java code.
Implementation
Native File (mynative.cpp)
extern "C" JNIEXPORT jobject JNICALL
Java_com_android_nativecpp_MainActivity_createJniNativeReference(JNIEnv* env, jobject obj, jint size) {
void* buf = malloc(size);
jobject sharedbytebuffer = env->NewDirectByteBuffer(buf, size);
return env->NewGlobalRef(sharedbytebuffer);
}
extern "C" JNIEXPORT void JNICALL
Java_com_android_nativecpp_MainActivity_deleteJniNativeReference(JNIEnv* env, jobject obj, jobject sharedbytebuffer) {
env->DeleteGlobalRef(sharedbytebuffer);
void* buf = env->GetDirectBufferAddress(sharedbytebuffer);
free(buf);
return;
}
Java file (MainActivity.java)
import java.nio.ByteBuffer;
private ByteBuffer mJniReference;
public native ByteBuffer createJniNativeReference(int size);
public native void deleteJniNativeReference(ByteBuffer mJniReference);
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mJniReference = createJniNativeReference(1000);
}
protected void onDestroy() {
deleteJniNativeReference(mJniReference);
super.onDestroy();
}
EXPLAINATION
The reason for either of 1) or 2) is otherwise, the creating frame is then exited from the stack and the JNI local references are deleted.
This will end all the threads in C++ when all std::thread references (which are not detached, ideally) are deleted.
In the non-detached case std::thread destructors are called on the main exit, or when a thread object goes out of scope and then terminate() is called.
In the detached case the detached threads exit on app close which kills the host process. They can also be garbage collected.
I have found the clone() method of Object in Java:
protected native Object clone() throws CloneNotSupportedException;
Is the source of this method available? Maybe in OpenJDK?
From jdk/src/share/native/java/lang/Object.c
static JNINativeMethod methods[] = {
{"hashCode", "()I", (void *)&JVM_IHashCode},
{"wait", "(J)V", (void *)&JVM_MonitorWait},
{"notify", "()V", (void *)&JVM_MonitorNotify},
{"notifyAll", "()V", (void *)&JVM_MonitorNotifyAll},
{"clone", "()Ljava/lang/Object;", (void *)&JVM_Clone},
};
Meaning its a function pointer(probably done so they could implement platform-specific native code)
doing a grep for JVM_Clone produces, among other things:
(from hotspot/src/share/vm/prims/jvm.cpp)
JVM_ENTRY(jobject, JVM_Clone(JNIEnv* env, jobject handle))
JVMWrapper("JVM_Clone");
Handle obj(THREAD, JNIHandles::resolve_non_null(handle));
const KlassHandle klass (THREAD, obj->klass());
JvmtiVMObjectAllocEventCollector oam;
#ifdef ASSERT
// Just checking that the cloneable flag is set correct
if (obj->is_javaArray()) {
guarantee(klass->is_cloneable(), "all arrays are cloneable");
} else {
guarantee(obj->is_instance(), "should be instanceOop");
bool cloneable = klass->is_subtype_of(SystemDictionary::Cloneable_klass());
guarantee(cloneable == klass->is_cloneable(), "incorrect cloneable flag");
}
#endif
// Check if class of obj supports the Cloneable interface.
// All arrays are considered to be cloneable (See JLS 20.1.5)
if (!klass->is_cloneable()) {
ResourceMark rm(THREAD);
THROW_MSG_0(vmSymbols::java_lang_CloneNotSupportedException(), klass->external_name());
}
// Make shallow object copy
const int size = obj->size();
oop new_obj = NULL;
if (obj->is_javaArray()) {
const int length = ((arrayOop)obj())->length();
new_obj = CollectedHeap::array_allocate(klass, size, length, CHECK_NULL);
} else {
new_obj = CollectedHeap::obj_allocate(klass, size, CHECK_NULL);
}
// 4839641 (4840070): We must do an oop-atomic copy, because if another thread
// is modifying a reference field in the clonee, a non-oop-atomic copy might
// be suspended in the middle of copying the pointer and end up with parts
// of two different pointers in the field. Subsequent dereferences will crash.
// 4846409: an oop-copy of objects with long or double fields or arrays of same
// won't copy the longs/doubles atomically in 32-bit vm's, so we copy jlongs instead
// of oops. We know objects are aligned on a minimum of an jlong boundary.
// The same is true of StubRoutines::object_copy and the various oop_copy
// variants, and of the code generated by the inline_native_clone intrinsic.
assert(MinObjAlignmentInBytes >= BytesPerLong, "objects misaligned");
Copy::conjoint_jlongs_atomic((jlong*)obj(), (jlong*)new_obj,
(size_t)align_object_size(size) / HeapWordsPerLong);
// Clear the header
new_obj->init_mark();
// Store check (mark entire object and let gc sort it out)
BarrierSet* bs = Universe::heap()->barrier_set();
assert(bs->has_write_region_opt(), "Barrier set does not have write_region");
bs->write_region(MemRegion((HeapWord*)new_obj, size));
// Caution: this involves a java upcall, so the clone should be
// "gc-robust" by this stage.
if (klass->has_finalizer()) {
assert(obj->is_instance(), "should be instanceOop");
new_obj = instanceKlass::register_finalizer(instanceOop(new_obj), CHECK_NULL);
}
return JNIHandles::make_local(env, oop(new_obj));
JVM_END
I found these files, but all they do is import the function from elsewhere. I can't find the actual source (try asking a Hotspot dev).
Object.c
jvm.h
Edit: Here's a link to the actual source online (Thanks user439407 for finding which file it was in)
I'm using GetStringUTFChars to retrieve a string's value from the java code using JNI and releasing the string using ReleaseStringUTFChars. When the code is running on JRE 1.4 there is no memory leak but if the same code is running with a JRE 1.5 or higher version the memory increases. This is a part of the code
msg_id=(*env)->GetStringUTFChars(env, msgid,NULL);
opcdata_set_str(opc_msg_id, OPCDATA_MSGID, msg_id);
(*env)->ReleaseStringUTFChars(env, msgid,msg_id);
I'm unable to understand the reason for leak.Can someone help?
This one is because if I comment the rest of the code but leave this part the memory leak takes place. This is a part of the code that I'm using
JNIEXPORT jobjectArray JNICALL Java_msiAPI_msiAPI_msgtoescalate( JNIEnv *env,
jobject job,
jstring msgid,
jlong msgseverity,
jstring msgprefixtext,
jint flag )
{
opcdata opc_msg_id; /* data struct to store a mesg ID */
const char *msg_id;
int ret, ret2;
jint val;
val=67;
jstring str=NULL;
jobjectArray array = NULL;
jclass sclass=NULL;
/* create an opc_data structure to store message ids of */
/* messages to escalate */
if ((ret2=opcdata_create(OPCDTYPE_MESSAGE_ID, &opc_msg_id))!= OPC_ERR_OK)
{
fprintf(stderr, "Can't create opc_data structure to store message. opcdata_create()=%d\n", ret2);
cleanup_all();
}
//////////////////////////////////////////////////////////
msg_id=(*env)->GetStringUTFChars(env,msgid,NULL);
opcdata_set_str(opc_msg_id, OPCDATA_MSGID, msg_id);
(*env)->ReleaseStringUTFChars(env, msgid, msg_id);
ret=opcmsg_ack(connection,opc_msg_id);
//////////////////////////////////////////////////////////
if(flag==0 && ret==0)
{
sclass = (*env)->FindClass(env, "java/lang/String");
array = (*env)->NewObjectArray(env, 2, sclass, NULL);
str=(*env)->NewStringUTF(env,"0");
(*env)->SetObjectArrayElement(env,array,0,str);
(*env)->DeleteLocalRef(env, str);
str=(*env)->NewStringUTF(env,"0");
(*env)->SetObjectArrayElement(env,array,1,str);
(*env)->DeleteLocalRef(env, str);
}
opcdata_free(&opc_msg_id);
if(ret!=0)
return NULL;
else
return(array);
}
In the one above is if I comment the sections between ///// I don't see any memory leak.
Release array object.
(*env)->DeleteLocalRef(env, array);