Should JavaCall be using global refs instead of local ones?

[zot]

The JNI docs say that local refs are only valid for the duration of a JNI call, yet it looks to me as if JavaObject holds onto its local ref until Julia garbage collects the JavaObject.

This seems like it would create unstable references. In fact I have seen JavaObjects that appear to change class spontaneously and I am wondering if there is a connection.

Should JavaCall be changed to use global refs instead of local ones?

[aviks]

I don't remember exactly, it's been a while, but I vaguely recall

• There is a limit on the number of global references that can exist
• There may be differences between calling java from C (what we do) and calling C from Java. Most documentation unfortunately deal with with latter case.

None of which is to say this is definitive and correct. I did struggle with this issue, but I thought I had found a solution that worked all around, but i could be wrong.

At this point I'd suggest changing things, and seeing if JavaCall/JDBC/Taro/Spark tests pass.

[zot]

Ah, OK. It's actually local references that are limited so I'll make changes... :).

https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#global_local

Local references are valid for the duration of a native method call. They are freed automatically after the native method returns. Each local reference costs some amount of Java Virtual Machine resource. Programmers need to make sure that native methods do not excessively allocate local references. Although local references are automatically freed after the native method returns to Java, excessive allocation of local references may cause the VM to run out of memory during the execution of a native method.