Perplexing GC Time Growth

[Jason Vasquez]

On Jan 8, 2008, at 16:40 , Steve Bohne wrote:
> Jason Vasquez wrote:
>> I peppered the native code with  DeleteLocalRef directives anywhere  
>> a local reference was declared, and  the number of JNI local refs  
>> now stays steady at 52-53 during full  load. (!)   The JNI  
>> documentation seems to indicate that I shouldn't  need to do that  
>> for these type of references, but in any case, that is  an extreme  
>> difference.
>
> Normally, local references should be deleted automatically when a  
> native method returns to Java.  One explanation for this behavior  
> might involve some thread sitting in a native method and generating  
> local references for a very long/indefinite amount of time, without  
> returning to Java. Is this a possibility?

These references are generated from a separate native thread calling  
up into Java.  The access pattern is a bit dodgy (legacy code here,  
folks :)):

void foo() {
...
       //ctl is some other object with a jenv member
       jobject job = ctl->jenv->CallStaticObjectMethod( ctl->fooCls,  
ctl->getInstanceMid );
       ctl->jenv->CallVoidMethod( job,
                                  ctl->newEventMid,
                                  fooId,
                                  eventType,
                                  state,
                                  data );
       ctl->jenv->DeleteLocalRef(job); //newly added
...
}

For C++ objects that have jenv as a local member or variable, it seems  
that the local refs are cleaned up normally.  In access patterns of  
the sort listed above, 'job' doesn't seem to be deleted, even though  
'foo()' enters and exits quite quickly.

This whole pattern is very nasty to me, and ripe for refactoring, but  
for now, DeleteLocalRef seems to be the solution.

-jason