local reference lifetime

[Igor R]

Hello,

It's stated in various JNI documents that local references, used in a
native function, get released automatically as soon as the native
function exits.
However, I noticed that the local references, which I create in my
native functions, are not released automatically.
This has 2 immediate consequences:
1) if these are references to big objects/arrays, then I get "out of
memory" after a few iterations.
2) if these are references to small objects, then after some time I
get something like "no more room in reference table", and the
application crashes.

Thus, I have to call DeleteLocalRef() for every reference I create.

So my question is why it happens? The thread, which executes these
native functions, is a native thread (it's launched in c++ code) --
can it be the reason?

Thanks.

[Olivier Guilyardi]

From what I understand, when you call a native function, and that it allocates
local references, the VM can only free them when this native function returns.

If your function allocates a lot of local refs before it returns, then you need
to delete them yourself while the function runs.

If the locale refs get allocated within a thread, then I think that the VM just
can't determine when it can delete them, since it doesn't know when they're not
used anymore.

--
Olivier

[Igor R]

> If the locale refs get allocated within a thread, then I think that the VM just
> can't determine when it can delete them, since it doesn't know when they're not
> used anymore.

Yes, I suspect that's the reason. Actually, the flow in my code is
reversed: I create a native thread, which attaches to JVM and
sometimes calls java functions, so the native call never "returns" to
JVM.

So, now my question is *what* should be treated as local references?
AFAICS, it's not really documented (maybe because in the "normal" flow
there's no need to care abut them). Is it *any* value of type jobject
(and its descendants), returned from any jni function?

[Olivier Guilyardi]

I think that the terms "reference" has to be understood in the context of
garbage collection: when the reference count of an object is zero, then the VM
might free it. So it should affect any object, either created in JNI or returned
by a jni or Java function. A given object may then be referenced one, two or
more times, etc...

That said, this explains a lot:
http://www.netmite.com/android/mydroid/1.6/dalvik/docs/jni-tips.html#local_vs_global_references

It says that the VM is only required to reserve 16 locale ref slots, and also
mentions the thread situation.

--
Olivier

[Igor R]

> That said, this explains a lot:
> http://www.netmite.com/android/mydroid/1.6/dalvik/docs/jni-tips.html#local_vs_global_references
>
> It says that the VM is only required to reserve 16 locale ref slots, and also
> mentions the thread situation.

Ahaa, great article. Well, at least my guesses were correct :).

Thanks a lot!