Use of JNI::DeleteLocalRef on parameters is causing excessive output of warnings

[MxSRF]

For Android the generated cpp-code contains lines like:

jniEnv->DeleteLocalRef(j_parameter);

... if j_parameter is a Java-object that was passed as jobject and after it has been converted or wrapped to it's cpp-counterpart. This line cause the following output on logcat during runtime:

"Attempt to remove non-JNI local reference, dumping thread"

This seems to be harmless but is causing overhead and is cluttering the logs with unnecessary messages. Furthermore I found no hints that it is recommended to call JNI::DeleteLocalRef on passed parameters of a JNI-call. The references should at least automatically be deleted once the JNI call returns to Java. So is it really necessary to insert such calls and bear the warnings? What is the reason for? Could an app run out of local references if the djinni-tool would not insert this lines? In which cases?
One could think of function that have a lot of parameters or create a lot of djinni::LocalRef in order to call callbacks maybe with objects in array. Or can deep callstacks back and fourth between Java and cpp exceed the limit of local references?

In that case one possible solution would be to have an option to switch the generation of "early deletion of passed parameters" on or off and leave it to the users responsibility to find out if it is necessary to use this feature.

[artwyman]

Hmm, I'm pretty sure at the time Djinni was created there wasn't any such warning, and the approach was just to make all references (parameters or otherwise) got deleted explicitly when C++ knew they were no longer in use. That's important for local references created dynamically, which can overflow the storage stack if created inside a loop, or on a C++-owned thread which never returns to Java. Doing so for parameters to calls from Java is generally unnecessary, but would take more effort to special-case, which is probably why nobody's ever done it. In theory there could be cases where freeing earlier would help with very-deep callstacks, but I don't think that's an intended property of the current solution, since it'll generally let those local references be freed by the destructors of stack variables in C++ anyway.

I wouldn't object to a PR which changed the generator to try to avoid these warnings.

[MxSRF]

Yes that is exactly my understanding of the problem: there may be cases where early freeing the passed parameter is necessary to avoid an overflow. Therefore I thought it would be good to have an option. But however I also agree that is an extra-effort to separate cases of parameters and other local references.

I would also agree that the problematic warning has probably not existed when Djinni was created. It seems that it was introduced with the ART compiler/engine on Android which superseeded the Dalvik engine. Maybe they even have (slightly) different handling of the local references.

Unfortunately I found no information about the internal handling of parameters and local references by the Java engines/compiler and about the relevance of the warning. Even while it seems harmless it may irritate developers again who use Djinni and waste their time in researching about the origin of the warning. Beside that it clutters the log and can make you overlook important warnings. But I also agree that this is all minor problems. Maybe I find some time to look deeper in the generator code and suggest a solution myself.

Thank you very much for the fast response!